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3-1-2 العمليات 8د 000000 
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2-2-2 البتية التحتية الخاضة بالتواصضل والتنسيق 6 


2-2-2-2 البنية التحتية المتعلقة بالاجتماعات 


للمباحثات التفاعلية والاستفسارات .. 
4-2-2-2 تتبع عيوب البرنامج وإدارة التغيبر . 

3-2 إدارة المعرفة: تصميم البرمجيات والنماذج والتوثيق . 
وغوت كان الحة التحعة لؤدازة العرفة 00000 
2-3-3 البية العنية لؤدارة المعرفة 0000000 
4-2 إدارة إعداد البرمجيات 100 
1-4-2 'الخنيان البثية الفحمة لإدازة إغداد البرمضيات ؛ 
2-4-2 البنية التحتية لإدارة إعداد البرمجيات ا 
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1-2-4-2 إدارة التكامل والوحدات المبرمجة 287 


3-4-2 إدارة إعداد البرمجيات لتسهيل التطوير 


البرمجى الشامل تر 28 

دنعف المهام المحددة بدقة امح 290 

2-3-4-2 المسؤوليات الحصرية 2 

5-2 الملخص والاستنتاجات ل 20 
6-2 أسئلة للمناقشة ا ا ا 20 
المراجع ال ا ل م 20 
الفصل الثالث عشر : التواصل ال اللا 20 
1-3 أدوات التحكم بالتواصل امت لكا مل اشم 2981 
2-3 عوائق التواصل 0 
3-3 التواصل والتنسيق ا 00 
4-3 التواصل والتحكم سا ا ا اي 5011 
1-4-3 تحليل الشبكات الاجتماعية 308 
5-3 الملخص والاستنتاجات د 
6-3 أسئلة للمناقشة 10 
المراجع ا 


القسم الخامس: دراسات الحالة 


الفصل الرابع عشر: مشروع الأستديو العالمي 2005 319 
1-4 مشروع (8151116) 9ب-ب 0 ز1ةؤز1ة1010010111 
2-4 التحديات التي تم مواجهتها في السنة الأولى من 

تطوير نظام (315116) ا و5300 
4 3 المنهجية للسنة الثانية من تطوير نظام (6غ3051.1) 9525 


14 


6-3-4 أمور استراتيجية : التخطيط والتحكم 500 
1-6-3-4 توزيع العمل و السخفاسو ا 
2-6-3-4 التخطيط للمشروع والتحكم به 1 

7-3-4 ضمان الجودة لذ[ 1 2071 

8-3-4 التدريب 0" 


4-4 الوضع الحالي للجهود المبذولة في تطوير نظام 
(ع0151:1) ا ا ا 
5-4 الخطوات التالية لمشروع نظام (16ْآ3/51) 5000 


المراجع ملاوع مات برا بكاو او و ار ا ا 


يك ا 000 
2-5 التحليل الشامل 21 
5 3 استراتيجيات التصميم 00 


4-5 هيكلية نظام معالجة البيانات دجدجدجن0د320000000005050 


5-5 التخطيط للمشروع 0 


6-5 إدارة المشروع لك 
7-65 دروس مستفادة 640 006221664021664 62 42 4 اج 2ه 


الفصل السادس عشر: نظام المعلومات المالية 


1-6 متطلبات المشروع الجديد 0 


2-6 تنظيم عملية التطوير ا 
3-6 الهيكلية 5 


القسم السادس: ملاحظات ختامية 


الفصل الثامن عشر : الاستنتاجات 
1-8 قضايا تتعلق بتطوير البرمجيات الموزّعة المراكز 


2-868 وصفة للنجاح 121101111011119 
3-8 تبادل أفضل المنهجيات ا 


1-17 تمهيد 111111110110111 


2-7 التحليل الشامل 0 0000000000 
3-7 هيكلية نظام إدارة المباني الآلي ا 


4-8 الملخص والاستنتاجات 11100 
المراجع ا 00 
الثبت التعريفي 0 
ثبت المصطلحات لخن لاس ا لمانو الما ل 1 
الفهرس بز ة ة ة ةز ز ز ز ز ز ز ز ز ز ز 000502 ا 
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تقديم 


سلسلة كتب التقنيات الاستراتيجية والمتقدمة 
ضمن مبادرة الملك عبد الله للمحتوى العربي 
يطيب لي أن أقدّم لهذه السلسلة التي جرى انتقاؤها في 
مجالات تقنية ذات أولوية للقارئ العربي فى عصر أصبحت فيه 
المعرفة محرّكاً أساسياً للنمو الاقتصادي الهف وات تو هه 
اللسئلة بالشعاون بيقن مغييدة انلك عند العؤير للعلوم والتقنية 
والمنظمة العربية للترجمة ويقع في إطار تلبية عدد من السياسات 
والتوصيات التي تعنى باللغة العربية والعلوم ومنها: 
أولة 'الننان الشفاى مودي القية الفرى المقعين فى لفان 
في 1428ه ‏ 2007 م الذى يو كد عبوز الاهتمام باللقة العري 44 وان 
تكون هي لغة البحث العلمي والمعاملات حيث نص على ما يأتي: 
(وجوب حضور اللغة العربية في جميع الميادين بما في ذلك وسائل 
التواصل» والإعلام» والإنترنت» وغيرها). 


ثانياً: «السياسة الوطنية للعلوم والتقنية» في المملكة العربية 
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السعودية التي انبثق عنها اعتماد إحدى عشرة تقنية استراتيجية هي : 
المياه؛ والترول والغاز»ء والبتروكيميائيات» والتقنيات المتناهية 
الصغر(النانو)» والتقنية الحيوية» وتقنية المعلومات» والإلكترونيات» 
والاتفيالاف » والسوكاشة: والقفياء :و الظير الل والطافةه .د والنتراة 
المتقدمةه واليئة: 


قالغا #:هبادزة العلف»عيل اللا للتجترى العرين القن شل اهيا 
ما جاء في البند الأول عن حضور اللغة العربية في الإنترنت» حيث 
تهدف إلى إثراء المحتوى العربي عبر عدد من المشاريع التي تنفذها 
داخل المملكة وخارجها. ومن هذه المشاريع ما يتعلق برقمنة 
المحتوى العربي القائم على شكل ورقي وإتاحته على شبكة 
الإنترنت» ومنها ما يتعلق بترجمة الكتب المهمة. وبخاصة العلمية» 
ما يساعد على إثراء المحتوى العلمى بالترجمة من اللغات الأخرى 
إلى اللغة العربية بهدف تزويد القارئ العربي بعلم نافع مفيد. 

تشتمل السلسلة على ثلاثة كتب فى كُلْ من التقنيات التى 
حددتها «السياسة الوطنية للعلوم والتقنية». واختيرت الكتب بحيث 
يكون الأول مرجعاً عالمياً معروفاً في تلك التقنية» ويكون الثاني كتاباً 
جامعياً» والثالث كتاباً عاماً مُوجَهاً إلى عامّة المهتمين» وقد يغطى 
ذلك كتاب واحد أو أكثر. وعليه» تشتمل سلسلة كتب التقنيات 
الأمتتراتجية والمتقدية عل ما دمسموعة كلانة وثلاتي: كنانا مدر ماه 
كما خصص كتاب إضافى منفرد للمصطلحات العلمية والتقنية 
المعتمدة فى هذه السلسلة كمعجم للمصطلح. 

وقد جرى انتقاء الكتب وفق معايير منها أن يكون الكتاب من 
أمهات الكتب في تلك التقنية» ولمؤلفين مشهود لهم عالمياًء وأن 
يكون قد صدر بعد عام 22000 وأن لا يكون ضيّق الاختصاص 
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بحيث يخاطب فئَةً محدودةًٌ» وأن تكون النسخة التي يترجم عنها 
مكتوبة باللغة التي ألف بها الكتاب وليست مترجمة عن لغة أخرى» 
وأخيراً أن يكون موضوع الكتاب ونهجه عملياً تطبيقياً يصب في 
جهود نقل التقنية والابتكار ويساهم في عملية التنمية الاقتصادية من 
خلال زيادة المحتوى المعرفي العربي. 
إن مدينة الملك عبد العزيز للعلوم والتقنية سعيدة بصدور هذه 
المجموعة من الكتب. وأود أن أشكر المنظمة العربية للترجمة على 
الجهود التي بذلتها لتحقيق الجودة العالية في الترجمة والمراجعة 
والتحرير والإخراج» وعلى حسن انتقائها للمترجمين المتخصصين» 
وعلى سرعة الإنجاز. كما أشكر اللجنة العلمية للمجموعة التى أنيط 
كنا الأشراف على العانها فى المنطفة كا ناك تلات فى ماني 
الملك عبد العزيز للعلوم والتقنية الذين يتابعون تنفيذ مبادرة الملك 
عبد الله للمحتوى العربي. 
الرياض 20 ربيع الأول 1431 ه 
رئيس مدينة الملك عبد العزيز للعلوم والتقنية 


د. محمد بن إبراهيم السويل 
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مقدّمة بقلم مانفريد بروي 


لقح كان توي انظمة الترمسياة وسيظل نهذ دسي 
تواجهنا بالتحديات» وبالأخص بعدما أصبحت مشاريع البرمجيات 
متعددة الاختصاصات وموزعة. فقد صاغ فريتز باور (7عندة8 21162) 
مصطلح «هندسة البرمجيات» في مؤتمر عقد في غارمش 
(«اءونصصة0) فى أواخر الستينيات من القرن الماضى. ولقد شهدنا 
ينك لضي سنة خدف دنيا كبيرا فى شري مهاد كد 
البرمجيات إلى مهام أكثر وضوحاً ومدارة بشكل أفضل يمكن 
التنبؤ بنتائج اتباعها. وقد تحقق هذا بفضل التقدم الهائل في وضع 
نماذج لدورة د البرمجيات والتقدم في تحديد التقنيات 
الأفضل التي توظف في تخطيط وإدارة المشاريع والتصاميم 
المتطورة والمنهجيات الأكثر ملاءمة وتقنيات النمذجة الممتازة 
والوسائل المحسّنة. وقد أصبح لدينا اليوم إدراك أفضل ورؤية 
أعمق لأحكام ومبادئ وعوامل نجاح تطوير البرمجيات. ومع هذاء 
لا يزال هناك العديد من التحديات التى تواجه هندسة أنظمة 
البرمجيات الضخمة. ١‏ 


في الوقت الذي تتوزع فيه الشركات وشبكات الشركات وتتعاون 
حول العالم» يكون خيار القيام بالعمليات من خارج الحدود (-08 
عهنةهطة) أكثر شعبوية في مجال الإدارة» غير أن هذا الخيار يعتبر 
البرمجيات في المشاريع الموزعة دي عت يتم تطوير البرمجيات 
في عدة أماكن متباعدة عن بعضها بعضاء أحد أهم تحديات العصر 
المورّعة المراكز (655) والتغلّب عليها. وعلى الرغم من أن هناك 
البرمجيات الموزرّعة المراكزء غير أننا لم نكتسب الخبرة الكافية عن 
المناهج التجريبية أو عن مبادئ أو أحكام تطوير البرمجيات الشاملة» 

تُعتبر هندسة البرمجيات مهمَّةً صعبة في كل الأحوال. ومع 
هذاء يتعيّن علينا فى مجال تطوير البرمجيات المورّعة المراكز 
مواجهة المزيد من التحديات. وبعض هذه التحديات واضح ومعروف 
كاختلاف المناطق الزمنية مثلاً أو كصعوبات التواصل بين أعضاء 
الفريق الواحد لاختلاف الثقافات الاجتماعية التى ينتمون إليها. بينما 
يكون بعضهم الآخر أكثر دقة مثل بناء الثقة بين فرق العمل والاهتمام 
تحقيق الكثير منها في استخدام منهجيات تطوير البرمجيات الموزّعة 
المراكز. 

حتى الآنء تعتبر معرفتنا المنهجية عن تطوير البرمجيات 
المورّعة المراكز ضعيفة نسبياً. وهناك العديد من الأسئلة التى يتعيّن 
الإجابة عنها فى مجال تطوير البرمجيات المورّعة المراكز. وهذه 
الأسئلة تتعلق بالمواضيع الآتية : 
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© نماذج دورة حياة البرمجيات 

© تخطيط المشاريع وتقويمها وإدارة المخاطر المتعلقة مها. 

© الآثار المترتبة عن تطوير البرمجيات المورّعة المراكز على مرحلة 
تطوير البرمجيات» كهندسة المتطلبات» والتصميم» والتنفيذ» 
والتكامل» والاختبار. 


© ضمان الحودة 

© تنظيم فريق العمل 

© مهارات فريق العمل والتدريب المتخصص 

© توزيع العمل والمسؤوليات 

© تنظيم عملية التواصل 

© التأثير على المنتج البريجي وبالأخص على الهيكلية 

© البنية التحتية والوسائل الداعمة 

بالإضافة إلى هذه المسائل التقنية والمنهجية المفصّلةء هناك 


أسئلة أخرى تهمنا من وجهة نظر إدارية» مثل: 


© ما هي عوامل وأسس النجاح؟ 

© ما هو الآثر الاقتصادي؟ 

© ما هي المشاريع التي يناسبها مبدأ تطوير البرمجيات المورّعة المراكز 
أكثر من غيرها؟ 

لذا قام قسم البحوث في شركة سيمنز في برينستون بإجراء 


التجارب في مجال تطوير البرمجيات الموزّعة المراكز عام 2003 
ضمن مشروع الأاستديو العالمي (2»)658 وهذا مدعاة للسرور ويعتبر 
ذا قيمة فى حد ذاته. ولقد أجريت تجربتان» منذ ذلك الوقت» مدة 
كل مهما غاه واحد وقةة الشركت: العدرة من التعاتعاطة حول العام 
في التجربة الأولى في العام المدرسي 4 2005» وأما التجربة 
الثانية فقد أجريت بعد عام واحد. 
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لقد كانت الأهداف من وراء هذه التجارب واضحة. فقد هدف 
المشروع إلى تحصيل البيانات التجريبية في تطوير البرمجيات الموزّعة 
المراكز بالإضافة إلى العثور على العمليات والأدوات وطرق التعاون 
المناسبة. وقد ساهمت هذه التجارب بزيادة خبرتنا في كيفية تنظيم 
مشاريع تطوير البرمجيات الموزّعة المراكز حتى نكفل نجاحها. وقد 
كانت طرق تخطيط التجارب واجراؤها أقل وضوحاً في مرحلة 
التطوير الأولية عام 2003. 

في الواقع» من المهم إجراء هذه التجارب من دون الأخذ 
بالاعتبار المخاطر الاقتصادية الهائلة التى تتعرض لها الشركات حين 
قيامها بالخطوات الأولى في تطوير البرمجيات الموزرّعة المراكز 
وتطبيق هذه المنهجية على برنامج خاص بالحياة اليومية. لذاء فإنه لا 
البرمجيات الفعلية حيث نواجه مشكلة إبقاء حالات القصور سراً 

ما يمكنني قوله عن مشاركتي في مشروع الأستديو العالمي 
بطرق عديدة ورؤية مجموعة البحث الخاصة بي وهي تشارك في 
التجربة لمدة عامين في جامعة ميونخ التقنية» هو أنها كانت تجربة 
ممتعة جداً وقيّمة للغاية. وكان من المشجّع أيضاً رؤية الباحثين 
والطللاب المشتركين في المشاريع يكتسبون الكثير من الخبرة في 
تطوير البرمجيات الموزّعة المراكزء ويصبح لديهم إدراك أوسع عن 
المسائل المتعلقة بتطوير البرمجيات. 

نقدم في هذا الكتاب مجموعة ممتازة لحصيلة عامين من النتائج 
والاستنتاجات لمشروع الأستديو العالمي. كما إنه يحوي الأساس 
الأولي للبيانات لتطوير البرمجيات المورّعة المراكز. ومع ذلك» فإن 
هذا الكتاب لا يقوم فقط بإعطاء تقارير عن مشروع الأستديو 
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العالمي» بل ما يفوق ذلك أهمية هو أنه يقدم عدة ملاحظات 
ونصائح عن كيفية تنظيم مشاريع تطوير البرمجيات الموزّعة المراكز 
مع الأخذ بعين الاعتبار القيام بتطوير البرمجيات الموزّعة المراكز 
بنجاح. وتعتمد هذه النصائح على حصيلة الخبرة في مشروع الأستديو 
العالمي» والتحليل العميق ومعرفة خلفية الباحثين المشتركين. وقد 
ثبت هنا مدى ضرورة توفر الخبرة لدى فريق العمل والباحثين 
والتدريب طويل الأمد الذي خضعوا له في مركز أبحاث شركة سيمنز 
في برينستون في مجالات العمل. والمتطلبات الهندسية» وفي 
التصميم والمنهجية والأدوات الداعمة. 
ما أحبه في هذا الكتاب هو أنه عرض سهل لعدد من المواضيع 
المعقّدة والصعبة. ويعتبر هذا الكتاب ذا قيمة لمن له اهتمام بتطوير 
البرمجيات على هذا النحوء ولكنه يعتبرء» بالأخصء. ذا قيمة عظيمة 
للباحثين والمطورين ومديري المشاريع المهتمين بتطوير البرمجيات 
الموزطة الماك والمشاركين فنها: 
ويسرّني أن أشكرء على وجه الخصوصء فريق عمل مركز 
أبحاث شركة سيمنز على جهوده لإتاحة الفرصة لمجموعات البحث 
والعمل على نشر نتائج تجاربها المثيرة» واعتبار ذلك مساهمة منه في 
بناء المعرفة المتعلقة بهندسة البرمجيات. وإنه ليسرني» بصفتي أحد 
المشاركين في التجارب مع فريق عمل من جامعة ميونخ التقنية» أن 
أرى هذا الكتاب يخرج إلى النور. ويعتبر هذا الكتاب وثيقة قيّمة 
ومساهمة مهمة في المواضيع التي تحظى باهتمام متزايد» والتي لها 
أثرها فى الاقتصاد العالمى وفى المهارات الهندسية الخاصة بنا. 
ا 0 مانفر يد بروي (ومعظ لعتسدكة) 
رئيس هندسة البرمجيات والأنظمة 
كلية تكنولوجيا المعلومات 
جامعة ميونخ التقنية 


21 


يبذل الفيزيائيون المتخصصون بعلم الجزيئات الكثير من 
الوقت والجهد والمال لصدم الجسيمات صدما عنيفاً بعضها 
ببعض. ولا بد أن لديهم أسباباً منطقية لفعل ذلك - فعادةً لا 
يكون من الممكن مراقبة السلوكيات المهمة عندما تكون 
الجسيمات في بيئتها الطبيعية مترابطة مع بعضها بعضاً. إذ تساعد 
التصادمات القوية على بعثرة الجزيئات» وبعثرة الطاقة في كافة 
الاتجاهات. وبمراقبة الجزيئات فى وضعية التشتت وبطاقة عالية 
جداًء يكون هناك فرصة أفضل مولن مان القرى. الشف البن 
كانت كامنة طوال الوقت. ش 


تقوم المشاريع الموزّعة جغرافياً - وبشكل غير مقصود ‏ بوظيفة 
مشابهة في مشاريع تطوير البرمجيات. ونحن كممارسين وباحثين» لا 
نكف عن تعلّم المهارات الضرورية والمتنوعة وبشكل سريع التي توفرها 
المشاركة الفعلية في الموقع وفرص التواصل والتعاون والمحتوى 
المشترك الذي تقدمه: لقد بدأنا ندرك جميعاً أن الفرق: الموزّعة 
جغرافياً تأخذ مسارات غير متوقعة» إذ لم نكن نعي أهمية «عمل 
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التنسيق» الذي يتطلبه المشروع» وكيف يتم هذا التنسيق بشكل غير 
ملحوظ في حال كان الأفراد يعملون» ببساطة» معا في مكان واحد. 

لا يُقصد مما سبق تزويد القارئ باستعارات مبالغ فيها أو 
ترفيهه» ولكن المقصود القول بأن هناك طريقتين على الأقل لقراءة 
هذا الكتاب الممتاز الجديد. إحداهما هى قراءته كما هدف الكتّاب» 
كدليل لإدارة الصعوبات المتعلقة بالمشاريع المورّعة» وذلك بالاعتماد 
على الخبرة المكتسبة» ودمج العديد من التقنيات السليمة والراسخة 
أو الابتكار في حال عدم وجود وسائل متوفرة. فهم حين يصفون 
طريقة ما وليس المقصود هنا طريقة معينة» فإنهم يجتهدون لإيضاح 
طريقة التعامل مع المشاريع الموزّعة جغرافياً مع إعطاء أولوية خاصة 
للمراحل الأولى الصعبة. ويجمع الكتاب عناصر من منهجيات لا 
يتوقع المرء أن تتعايش سلمياء كالعملية المنطقية الموحدة (807) 
ومنهجية سكروم (تنناته5). ويدعو الكتاب إلى التنقّل بين اتجاهات 
قد تبدؤ“فىئ باد "الأمر متتاقضة ب مفلا أن تكون. أكثر سرحة أو أكثر 
تشدداً ‏ ولكنك حين تتعمق في المادة» وتطّلع على الأفكار المطبقة 
فى دراسة الحالة المونّقة جيداً. ستدرك أن الحكمة من الكتاب أعمق 
كير من «أن تكون سريعة» أو أن «تتشدد في تنظيم عملياتك». 
فالكتاب يُشرك القارئ في التفكير حول ما الذي يجب أن يكون 
يع وأي المواضيع التي تحتاج إلى نظام متشدد ولماذا. وفي حين 
يتعرض الكثير من القرّاء لإغراء تطبيقه مثل وصفات كتب الطبخ» 
فليس الهدف منه أن يكون وصفة متبعة» ولكنه بالأحرى اقتراح نهج 
نجح معهم» بالإضافة إلى وصفات مدروسة تتلاءم مع الواقع وتتلاءم 
مع الأفخاخ السيئة على طول الطريق. وسواء قمت باتباع هذا النهج 
أو لم تتبعهء فإنك ستستفيد بالتأكيد من درس الجغرافيا. 

أما ما يقودني إلى الطريقة الثانية لقراءة هذا الكتاب فهو كونه 
مصدراً للفهم المتعمق للعوامل المؤثّرة في تطوير البرمجيات بشكل 
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أعم. وكعضو في مجموعة الباحثين المشاركين في مشروع الأستديو 
العالمي» فقد بدأت أدرك أن العديد من الأفكار التي قمنا بتطويرها 
واختبارها فى هذه «التجربة» يمكن أن تفيد فرق العمل المتشاركة فى 
الموقع بقدر ما تفيد الفرق المورّعة جغرافياً. لقد أظهرت تجارينا أن 
الشبكة الاجتماعية» على سبيل المثال» هي وسيلة قيّمة وعملية 
لمراقبة المشاكل التي يمكن أن تعترض التعاون يو الأفراد في أي 
مشروع كرسي إن وجد التشارك في الموقع أو لم يوجد. تعتبر 
التقنيات المستخدمة لتحقيق الوضوح في مهام العمل فائقة الأهمية 
للفرق الموزّعة» غير أنه من المرجّح أن تكون أيضاً مفيدة للغاية في 
حالات أخرى. لقد جعلني هذا المشروع أدرك أن التعاون هو 
المشكلة الرئيسة» وأن التشارك في الموقع هو فقط أحد الحلول 
المتوفرة ‏ وإن كان أقواها. وفي حال كان التشارك في الموقع غير 
ممكنء وضّح المؤلفون كيفية التعويض عن ذلك بحلول أخرى 
تساعد على إدارة المشروع بنجاح. 
يقدّم هذا الكتاب توليفة مدروسة جيداً من خبرات المؤلفين 
ومن الأدب المنشور ومن البحوث التي أجراها فريق عمل مشروع 
الأستديو العالمي. سيجد القارئ أن الكتاب هو دليل مفيد للغاية 
وعمليء ودليل تفصيلي للوضع الحالي الحديث. وعلى الرغم من 
وجود العديد من المشاكل التي لا تزال تحتاج إلى حلول في هذا 
المجال» غير أن قراءة هذا الكتاب جعلتني أدرك مدى التقدم الذي 
وصلنا إليه. 
جيمس د. هيرسليب ((16وط2ه11 .2 وعصدل) 
معهد بحوث البرمجيات 
الكلية الدولية لعلوم الحاسب الآلي 
جامعة كارنيغي ميلون 
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انطلقت فكرة هذا الكتاب بالتزام مركز البحوث في شركة سيمنز 
(5019) بالعديد من مشاريع تطوير البرمجيات الموزعة المراكز. 
وشركة سيمنز هي مؤسّسة متعددة الجنسيات يعمل لديها ما يزيد على 
0 مهندس برمجيات» ولها فروع في معظم الدول. 


لقد وجدنا خلال العمل على هذه المشاريع» مجتمعين» بأن 
البرمجيات الموزّعة المراكز يمكن أن تكون ذات فوائد جمّة في حال 
تم توليفها إلى مجموعة منظمة من المعرفة. 


ومع هذا رغبنا بداية في التحقق من مجموعة المعرفة هذه 
واختبارها وتوسيع قاعدتنا مع مجتمع البحث. وبالتالي» قام مركز 
البحوث في شركة سيمنز بإطلاق برنامج بحث عن مشاريع تطوير 
البرمجيات الموزعة المراكز عام 2003 بتعاون وثيق مع جامعة 
كارنيغى ميلون (1725169هلآ هو1اء]2 ءنععممة0) وكلية هارفرد للأعمال 
(اممطء؟ 9 11217214]) والمعهد الدولي لتكنولوجيا المعلومات 
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فى بانغالورء وجامعة مونماوث (1[019615169آ 0]5اهمتم30)» وجامعة 
رلا بنسلفانيا ((أ55ء دنآ علها5 هدهء©)» وجامعة ميونخ التقنية 
(طعنصد]38 5ه 'روانوع نتم [] لمعتصطءء1)». والجامعة البابوية الكاثوليكية 
فى ريو غراند دي سول 1810 0 'إأأواء عنصلا عتامطنلةن لمعقتاصمط) 
(1نا؟ عل علصة: ». وجامعة ليمريك (اءت7عصنآ 1ه نوأنوع'تمنا). إن 
هذا الكتاب هو حصيلة الخبرة المتراكمة التي اكتّسبت من عدد من 
متاريع وير الإرسحياك الموزعة المر اكز في شرك سيمي وافن 
التجارب التي أجرتها مجموعات البحوث التابعة لها والمؤلفة من 
ثماني 50 فى خمس دول عبر أربع قارات. إن للحكمة ثلاث 
دعائم رئيسة هي : (1) أفضل الممارسات لخبرة المشروع التي جعلت 
هذا الكتاب متماسكاًء (2) تحليل أدبي مكنّف قام بتوسيع قاعدة 
الخيوة 01 الصمكا الصخريي الذي لم رينم من قبل لمجال لطوير 
البرمجيات الموزرّعة المراكز والذي أمدّنا برؤى غير اعتيادية. 


إستتاداً إلى هذه" الخبرة المتراكمة»- قمنا (بتحديد عدد مك العوامل 
الرئيسة لنجاح مشاريع تطوير البرمجيات المورّعة المراكز. ففي حين 
تكون هذه العوامل مفيدة لكافة المشاريع» تكون قضية العمل 
والضرورة أعظم شأناً عندما يتم توزيع المشاريع جغرافياً عبر عدة 
مناطق زمنية» مع فرق بعيدة لم تعمل معا من قبل» ومضاعفة بسبب 
اختلافات اللغة والثقافة. ولكل من هذه العوامل قمنا بتنظيم أفضل 
الممارسات وحددنا أطراً عملية لها مع إعطاء توجيهات كبرى عن 
كيفية عمل أفضل الممارسات في مشروع ما. 


أثناء عملنا على إنجاز هذا الكتاب» لاحظنا أيضاً رغبة لدى 


المهندسين العاملين في مشاريع تطوير البرمجيات الموزّعة المراكز 
لتبنّى ممارسات تطوير البرمجيات الذكية التى تفضل العمليات الخفيفة 
بالحد الأدنى من الوثائق التي يمكن أن تتكيف ديناميكياً مع متطلبات 
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المشروع. وقد يعتقد المرء أن التطوير الموزع يمكن أن يحتاج إلى 
الكثير من الوثائق بسبب متطلبات التواصل المرتفعة. وإن بدت 
متناقضة» فقد قادتنا هذه الملاحظات إلى التفكير في الجمع بين 
هذين الاتجاهين. 

يقدم الكتاب منظوراً فريداً من نوعه عن السرعة الشاملة» 
المفهوم الذي يصف التقاء حركتين ‏ موزّعة عالمياً وتطوير البرمجيات 
السريعة. لقد أدركنا أن الكثير من الممارسات السريعة تعمل بشكل 
أفضل في بيئة عمل تشاركية» لذا حاولنا الحث على اعتماد 
الممارسات السريعة ححيكها لرم الأمر' لتحطقط بمزاياها وقباس. المهجية 
لتحقيق سياق تطوير البرمجيات الموزعة المراكز. وقد حققنا هذا عن 
طريق تطوير وتحديد تهيئة البنية التحتية والعمليات والآليات وأفضل 
الممارسات التي تتيح أفضل التبادلات بين النظام والعمليات السريعة. 
وينصبٌ التركيز بالأخص على تطورات المنتج التي تتطلب هيكلية 
برمجيات جديدة أو معذّلة. كما ينصب تركيزنا على المراحل الأولية 
للمشروع نظراً إلى أهميته لمشاريع تطوير البرمجيات الموزّعة 
المراكز. 

هذا الكتاب مخصص لممارسى هندسة البرمجيات وطلاب إدارة 
النعازهم الميسدين بالنظوين العو اللبوتسبالفه كنا سيكرة نيد 
بالأخص لمديري المشاريع الذين يخططون لمشروع تطوير موزع. 
ولكن يمكن أن يجده المشاركون حالياً في مثل هذه المشاريع وسيلة 
مفيدة ومنظوراً جديداً عن هذا الموضوع. يمكن استخدام هذا الكتاب 
كملحق إضافي للدورات على المستوى الجامعي أو على مستوى 
التخرج في مجال إدارة مشاريع البرمجيات» وبالأخص حين مناقشة 
مواضيع محيطة بتطوير البرمجيات الموزع في عدة مناطق جغرافية. 

لقد قسمنا هذا الكتاب إلى خمسة أقسام رئيسة. قسم المقدمة 
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المكوّن من الفصلين الأول والثاني» الذي يطرح دوافعنا من وراء هذا 
العمل ويصف إطار عملية لتطوير البرمجيات الموزعة المراكز. كما 
تطوير البرمجيات المورّعة المراكز. 

تشكل الفصول من الثالث إلى الثامن قسم التخطيطء حيث نبدأ 
بنماذج متطلبات الأعمال التي يتم صقلها تدريجياً بدءا من ميزات 
المنتج إلى متطلبات النظام. وتزامناً مع متطلبات الجهد الهندسي» 
نقوم بتحديد متطلبات الهيكلية المهمة التي تؤثر في بنية النظام قيد 
النظر. 

ومن ثم نأخذ بعين الاعتبار بنية وسمات الفرق المورّعة لقياس 
قدرات أفرادها على خلق نظام في ضوء الهيكلية المعطاة. وتُستخدم 
هذه المعلومات لاستنتاج وحدات النظام ومواصفاته. ويتم إعداد خطة 
البرمجة والإصدار طويلة الأمد من مواصفات متطلبات مزايا ووحدات 
النظام المطلوب بناؤه. ويتم في النهاية وضع الجدول الزمني لتنفيذ 
خطة البرمجة والتطوير وتحديد الموارد والمصادر والتكاليف» ويتم 
استخدام جدول زمني ذي منهجية عمل تكرارية لتحقيق التطوير 
المتزامن لعناصر النظام ضمن الفرق العديدة المورّعة في عدة مواقع 
حول العالم. 


يكون لعدد من العوامل أهمية أكبر عندما يتم توزيع المشاريع 
في عدة مناطق جغرافية. فيصبح التعاون والإدارة أكثر صعوبة بسبب 
المسافة التي تفصل بين الفرق الموزّعة في عدة مواقع. ففي حين 
يوجد هناك تقنيات ووسائل متاحة لتسهيل التواصل عن بُعدء 
فالبحوث التي قمنا بها تشير إلى أنها قد لا تكون فعالة بقدر 
الاجتماعات التي تتم وجهاً لوجه. لذا فإن إحدى طرق معالجة هذه 
المشكلة هي الحد من التواصل المفرط عن طريق تحسين درجة 


36 


التعاون بين الفرق. ويمكن تحسين التعاون عن طريق تقسيم النظام 
إلى أنظمة ومكوّنات فرعية حرة مقترنة. عندئذ يمكن لكل فريق 
العمل بشكل مستقل نسبياً عن الآخرين على نظام فرعي أو مكوّن 
معطى. ومع ذلك» ينبغي أن يكون هناك إدارة مركزية مسؤولة عن 
مواصفات هذه المكوّنات وبنيتها المشتركة وتنظيم تطورها الموزع 
عبر بناء منتظم للتطبيق القابل للاختبار. ويطلب كذلك من الأعضاء 
المباعدة بين الفرق المركزية والمورّعة في عدة مواقع ليتمكنوا من 
(1) تخطي المسائل المتعلقة بعدم معرفة الفرق بعضها بعضاًء أو 
لغات وثقافات بعضهم وغياب عمليات المشروع اليومية ليتابعها 
الأعضاء في المواقع المختلفة؛ (2) تكوين رؤية مشتركة للمشروع؛ 
(3) وبناء التعاون والثقة. ونناقش في الفصلين التاسع والعاشر بناء 
المؤسسة الذي لا يقوم فقط بتبني بناء الفرق» ولكنه أيضا يحقق 
تعاوناً بنَاءً بين الفرق المركزية وتلك الموزرّعة في عدة مواقع. 

يصف بند الرصد والمراقبة المسائل المتعلقة بجودة المنتج 
والعمليات في البيئة الموزّعة جغرافياً. كما إننا ندرك أنه عندما تكون 
الإدارة المركزية هي المالكة للمنتجء وهي التي توزع تطوير مكوناته 
الأساس على الفرق الموزّعة في عدة مواقعء فينبغي أن تُوْخذ بعين 
الاعتبار العناية الشديدة والعلاقات طويلة الأمد مع هذه الفرق» 
ومعاملتهم كشركاء لهاء وكمركز منافسة للمكوّنات التي تورّدها. يعتبر 
بناء هذه العلاقات مفيداً خصوصا حين اعتبار احتياجات الإسناد 
والصيانة المستمرة للمنتج تحت التطوير. وبما إن التواصل يعتبر 
تحدياً كبيراً بر بين الإدارة المركزية والفرق المورّعة في عدة ا 
وكاس داف الى تصن وها دكا طق رما يميق أن كر 
هناك اهتمام شديد بالبنية التحتية للوسيلة والكتننه عن أنماط 
التواصل بين هذه الفرق لتحديد الاستراتيجيات الفعالة لإدارة هذا 
التواصل . 
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نقدّم في الفصل الرابع عشر وحتى الفصل السابع عشر 
«دراسات حالة») تحصر خبراتنا (الجيدة منها والسيئة) من مشاريع 
متنوعة موزّعة في عدة مناطق جغرافية قمنا بالاشتراك فيها مع شركة 
هوية المنتجات والأشخاص المشاركين. 


تتنوع المشاريع من حيث الحجمء مع الأخذ بعين الاعتبار أن 
المشاريع الصغيرة ستكون أكثر صلة بالشركات الصغيرة» بينما الكبيرة 
منها ستفيد المؤسسات الكبرى. إن الأجزاء ذات الصلة بدراسات 
الحالة هذه تكون مترابطة فى كل فصول الكتاب.» حتى تعطى للقارئ 

نقدّم في الفصل الثامن عشر ملخصاً عن الكتاب» وتُلقي فيه 
الضوء على المسائل المتعلقة بمشاريع تطوير البرمجيات الموزّعة 
المراكز. ونقوم في هذا الفصل بتحليل المشاريع الناجحة والفاشلة 
على حدٍ سواء»ء ونعيد سرد آرائنا المذكورة في أكثر من مكان في 
الكتاب عن كيفية تنفيذ مشروع ناجح بواسطة فرق موزرّعة في عدة 
مناطق جغرافية. 

يقدّم القرص المدمج المرفق عرض فيديو يعطي لمحةٌ عامةٌ عن 
مشروع الأستديو العالمي المذكور في الفصل الرابع عشر. إضافة إلى 
ذلك» تم تقديم (77118 652©) كمثال على بنية إدارة المعرفة 
المستخدمة في المشروع التجريبي لتطوير البرمجيات الموزّعة المراكز. 
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شحر وعرفان 


هذا الكتاب هو نتاج خبرات العديد من أصدقائنا وزملائنا الذين 
شاركوا في مشاريع تطوير برمجيات موزرّعة مراكزها في مناطق 
جغرافية متباعدة. ونحن مدينون لهم لمشاركتهم لنا بخبراتهم هذه. 

ونود أن نسلّم بالعمل الممتاز الذي قام به الطلاب المشاركون 
في مشروع الأستديو العالمي» ونخص بالذكر زكريا الهدى هنتهعله2) 
(1100102 181» وستيفان غيرسمان (06150802 مذاعا8)» ولويز 
كوديرلي (606:11ن1 #ننه1). وألان مالون (6ه21210 صداه)ء وبرايان 
كيسي (إ095 صقة8)» وشارون إيد (ع220 ممعقطذ) . 

ندع الشكي الجويل للمد تين » الشعروقيق مده لديدا رفير 
المعروفين لملاحظاتهم المهمة. ونحن ممتنون بشكل خاص لباتريك 
كايل ([نع*! عل29:10)» وروبرت شفانك (عكلصةطءة خترءطهخ1)» 
وستيفن ماستيكولا (12ه0ء2/1356 معطامء)ق)» وجورج فونكس ع06018) 
(نمءعمط27» وسكوت كارني (لإعصمه0 6أمء6), ووليام شيرمان 
(مممتعطك مسمنلل111) . 


وقد سرّنا العمل مع دار أورباخ للنشر في تطوير هذا النص. 
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ونخص بالشكر الخاص المحرر» السينك جون فيزاليك مطمل) 
277322161 على توجيهاته وتشجيعه المستمر لنا طوال الوقت. 


وأخيراً نشكر عائلاتنا لحبهمء وصبرهم؟ ودعمهم لنا أثناء 
العمل على إعداد هذا الكتاب. ونحن نهدي هذا الكتاب لهم بكل 


موَدّة وحب. 
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تسارعت في الآونة الأخيرة وتيرة الانتقال إلى تطوير البرمجيات 
المورّعة المراكز عالمياً. وتعكس عملية التوزيع الجغرافي لمشاريع 
تطوير البرمجيات في مناطق جغرافية مختلفة» قامت بها شركة سيمنز 
وشركات برمجة أخرى كبيرة وصغيرة» هذا الاتجاه. فقد بذلت شركة 
سيمنز الكثير من الجهود في عملية تطوير العديد من البرمجيات 
باستخدام فرق عمل مورّعة» وتوظيف مفهوم أن هناك تأثيراً كبيراً 
لعملية توزيع وتطوير البرمجيات في دورة الحياة العملية» بما في 
ذلك الممارسات الإدارية (2005 ,[.21 66] ماءاوط:»11). وتتضمن عملية 
تطوير البرمجيات القابلة للتوزيع عالمياً (أو تطوير البرمجيات الموزّعة 
المراكز) العديد من الإيجابيات والسلبيات التي قد تؤدّي بأي مشروع 
تطوير برامج موزع إلى الخسارة ما لم يتم إدارته بحذر. ومن أهم 
الأمور المتعلقة بأي مشروع تطوير للبرمجيات الموزّعة المراكز هو 
التردد بين السرعة والانضباط في العملية. 


هذا الفصل هو مدخل عام عن تطوير البرمجيات المورّعة 
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المراكز ويعرض بعض التحديات المتعلقة بها. كما يعرض الحاجة 
إلى إدارة التعقيدات التي تعترض العملية بطرق فعالة وممنهجة بحيث 
تجنى الثمار المرجوة من تطوير البرمجيات المورّعة المراكز. 


1-1 ما هو تطوير البرمجيات المورّعة المراكز 

يمكن تعريف عملية تطوير البرمجيات الموزرّعة المراكز باختصار 
على أنها تطوير للبرمجيات توظف فرق عمل من مناطق جغرافية 
عديدة. وقد يكون» في بعض الأحيان» أعضاء فريق واحد من نفس 
الشركة أو المنظمة. وفي حالات أخرى قد يكون تعاوناً مشتركاً أو 
يُستعان بمصادر خارجية مختلفة. وقد تكون هذه الفرق فى دولة 
واحدة (في الواقع» تشير الدلائل إلى أنه إذا تباعدت الوق عن 
بعضها لأكثر من خمسين مترأء تكون المسافة أمرأً غير مهم)» أو قد 
تكون فى دول بعيدة عن بعضها بعضا (1984 ,2ء1آه). إن وجود فرق 
العمل الي بتطوير البرمجيات الموزرّعة المراكز ضمن مسافات 
فيزيائية متباعدة يسبب بعض التعقيدات والتحديات الممتعة التي أصبح 
العالم يتفهمها للتو. 


لقد أدت العديد من العوامل التكنولوجية والتنظيمية والاقتصادية 
إلى نمو عولمة مشاريع التطوير. ومع أن ذلك كان يحصل منذ العقد 
الماضى أو قبل ذلك» فإن عملية العولمة أصبحت الآن أقرب إلى أن 
وف القاقية وليس الاستثناء. وفي ما يأتي بعض من أكثر المحفزات 
شيوعاً وأفضلها تأسيساً في تطوير البرمجيات المورّعة المراكز 


(2005 ,[.1ة اع] اعاوطععط :1999 ,اعصصعدت) : 


© القوى العاملة المدربة محدودة في مجال التكنولوجيا وهي إلزامية 
لبناء النظم المركبة المعقدة المتطلبة في الوقت الراهن. 
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© التفاوت في تكاليف التطويرء ما أدى إلى اللجوء إلى توزيع فرق 
العمل فى عدة مناطق. 
© أصبحت أنظمة العمل التي تعتمد عل المناوبات أسهل وأيسر 
بسبب اعتماد الفروقات الزمنية بين المناطق ما أدى إلى تقصير 
المدة اللازمة لإيصال البرمجيات المنتجة إلى الأسواق. 
© التقدم في مجال البنية التحتية (مثل عرض النطاق الترددي المتوفر 
© الرغبة فى الاقتراب ما أمكن من السوق المحلية. 
في حين تختلف الصورة والحوافز الخاصة بمشاريع تطوير 
البرمجيات الموزّعة المراكزء تبقى إحدى صفات المشاريع أمراً 
ابتاً. فمن الصعوبة تنسيق المشاريع التي تكون فيها فرق العمل 
متباعدة في مناطق جغرافية مختلفة. بينما في مشاريع تطوير 
البرمجيات المنظمة التقليدية» عادة ما تكون هناك ممارسات قياسية 
وتكون مخرجاتها ومعالمها معروفةً» كما تتوفر لها قوالب مخصصة. 
غير أن بعض حالات التنسيق تتم بطريقة طارئة غير مجهّز لها 
مشيقاً.. ويبدزؤ أن .مهتدسى البرمجيات قد اكتسبوا فهماً حلسياً 
«الحقيقي» في عقول المصممين والمبرمجين وليس على الورق. 
وتشير الدلائل إلى أن الكثير من هذا «الفهم المشترك» يُشتق من 
العمل 'معا بشكل متقاوت.. إن 'القدرة غلى تبادل الحديث فى مقر 
العبدل بالشوم طن عترةانه" الجف أو: اننا «انورانحة العداء معاد ساعد 
في :تطوير مل هذا الفَهم الحشتكركة يشكل كيرء إن يتمكن زيد من 
فهم طريقة تفكير ليلى في ما يتعلق بالمشروع ويمكنه أن يترجم 
ملاحظاتها وأفكارها ويتبادل معها الآراء. فقد أدركت المنهجيات 
السريعة وحاولت دعم هذا النوع من التفاعل من خلال تطبيق بعض 
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الممارسات كالبرمجة الو (ع تمتمطوتع هام نتنوم) والاجتماعات 
اليومية ال (وع متأععممة مكمةاة) والتنظيم بين العملاء 
والمبرمجين. 


2-1 التنحديات التي تعترض مشاريع تطوير البرمجيات 
الموزَّعة المراكز 

تختلف مشاريع تطوير البرمجيات المورّعة المراكز في أشكالها 
وأحجامها. فليس مستغرباً اشتراك عدد من الأقسام والشركات 
والثقافات واللغات في مشروع واحد. وغالبا ما تجد بعض المشتركين 
في المشروع الواحد ممن لم يتقابلوا مع بعضهم البعض من قبل» 
وقد تتفاوت مستوياتهم وخبراتهم. وقد تكون لديهم دوافع تتعارض 
مع أهداف المشروع. تساهم هذه العوامل مشتركة في جعل التنسيق 
بين الفرق وإدارة التطور ومراقبة التقدم في المشروع أكثر صعوبة 
(2001 واعاوطمع1 لصهة كنكاعه81 :2001 ,هتكزه84 لصهة اعاوطععط) . 
أظهرت الدراسات السابقة أن إتمام مهام العمل كان يستغرق وقتاً 
أطول بمرتين ونصف حين استخدام الإعدادات الموزّعة بدلا من 
استخدام الإعدادات المنتظمة (2003 ر,كتناعاءه21 0صة اعاوط:ع1]) . 

هناك اعتقاد راسخ بأنه ما لم يتقابل الأشخاص المعنيون 
بالمشروع وجهاً لوجه» فقد يواجهون أوقاتاً عصيبة في تنسيق المهام 


[الهوامش المشار إليها ب#0)ء هي من وضع المترجم] 

(#) هو أن يعمل مبريجان معاً على جهاز حاسوب واحدء بحيث يتساعدان 
ويتشاركان في التفكير والتحليل والتنفيذ والتدقيق» وهو ما يسرع من عملية البرمجة ويضمن 
الدقة فى التنفيذ. 


أي أمور أخرى تخص العمل؛ وتعقد لضمان عدم استهلاك الوقت في نقاشات جانبية أو 
توسيع نطاق النقاش» وهو ما يُعتبر خسارة في الوقت المخصص للمشروع. 
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المعَقّدة عن بُعدء وخبرتنا تدعم هذا الاعتقاد. فحين ظهور تساؤل أو 
أمر معيّن يصعب تحديد الشخص الذي سيتم اللجوء إليه. فأي 
شخص يوجد في موقع بعيد لن يكون مطلعاً على سير الأنشطة التي 
يقوم بها أعضاء الفريق الآخرون الذين يوجدون في موقع غير موقعه. 
لذاء يتم تبديد الكثير من الوقت في محاولة إيجاد الشخص الذي 
يستطيع المساعدة. الأمر الآخر الممكن حدوثه هو أنه في حال عدم 
توفر المعلومات» يتم اللجوء إلى الافتراضات. وقد تتعارض هذه 
الافتراضات مع متطلبات العمل أو مع الافتراضات الأخرى التي 
تقررت في موقع آخرء وهو ما يسبب المشاكل في المشروع. 


عندما يتسلم مهندسو البرمجيات استعلامات أو تقارير تفيد 
تور ساكل رون مقافي 1 بحرن ل الك فلي سد و1 
أقل حماسة للاستجابة. فقد يترجمون التقرير حول المشكلة على أنه 
نقد لعملهم» أو قد لا يشعرون بأهمية المشكلة التي تواجه زميلهم 
الذي يوجد في موقع بعيد. فقد لا يستجيبون أبداً للرسائل الإلكترونية 
أو إذا ردوا عليها قد لا تكون ردودهم بنفس البراعة التي قد تتصف 
بها ردودهم في حال كانوا يعرفون الأشخاص الذين أرسلوها. علاوة 
على ذلك» فقد لا يتوفرون للمساعدة نظرأ إلى وجود عطل رسمية 
محلية لا يُحتفل بها في دولة الشخص الذي أرسل الطلب أو 
الاستعلام أو التقرين: كما إنه لبس.من المستغري أن تحعلقته الدواقع 
بشدة من فريق إلى آخر. وقد يخشى الفريق الموجود في أحد المواقع 
من أن المشروع ‏ في حال نجاحه ‏ سيحل محل منتج قديم كانوا 
مسؤولين عنه مسبقاً. وقد يمنع خوف فقدان الوظيفة الأشخاص في 
ذلك الموقع من مشاركة المعلومات التي يملكونها مع غيرهم 


باريحية. 
هذاء وتلعب عوامل فوارق الثقافة واللغة دوراً فى هذا المجال. 
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فعلى سبيل المثال» خبرنا وجود مقاومة ونفور من بعض الأشخاص 
غير المتحدثين باللغة الإنجليزية للمشاركة بفعالية في الاجتماعات 
التي تتم عن بُعد. فهم يفضلون توجيه أسئلتهم وما يعترضهم في 
المشروع عن طريق الرسائل الإلكترونية. وقد وجدنا (في وقت من 
الأوقات كنا مجموعة من الأميركيين) أن الرسائل الإلكترونية بطيئة 
ومحبطة. وقد تم اكتشاف ذلك ووّضعت بروتوكولات واضحة 
للتعامل مع الإشكاليات وذلك بعد فترة مهمة في هذا المشروع. كما 
قد تسبب الثقافة ونمط الحياة المحليان بعض الإرباك والخيبة. فعلى 
فيل الال تكوة سرفها جيدة غندها يتعلق الأمر ينقافة تندث الها 
بصلة مباشرة» بينما يختلف الأمر حين التعامل مع ثقافة أخرى 
تختلف عن ثقافتنا (نتجنب مراقبة التفاصيل). وأما فى المراسللات 
الخانقية: والدريه الالكعروني تق طبر أن الكقافة الساشيرة سيت 
إحباطاً بحيث يبدو النظراء غير قادرين على الفهم. فقد يتصلون هاتفياً 
ويسألون عن مواضيع ليست ذات علاقة قبل أن يفهموا المطلوب. 
كلما قل الأثر المباشر للثقافة» فقد يُنظر إلى النظراء على أنهم 
جاهلون. وتم حل هذه المفاهيم الخاطئة بعدما تم تنظيم سلسلة من 
الاتصالات الشخصية» وأصبح التفاني والجدية التي كانوا يعالجون بها 
المشاكل واضحاًء وتشكلت العلاقات الشخصية بينهم حين التقائهم 
مساءً لشرب القهوة. 


تنتهي العديد من القضايا اللوجستية الآأخرى باستغراق وقت أكثر 
من المتوقع. ومن الصعوبات والقضايا التي تستغرق وقتاً وتستنفد 
الموارد القيّمة ووقت المشروع محاولة معرفة كيفية تنظيم البنى 
التحتية التقنية والتعامل مع قضايا الربط التي تفرضها طبوغرافيا الشبكة 
الخاصة ومعرفة كيفية تنظيم الممارسات الإدارية والعمليات التنظيمية 
حيثما لزم الآمرء إلى غير ذلك. وإذا لم تؤخذ العوامل المذكورة 


دك 


أعلاه في الحسبان ولم يتم معالجتهاء فإن احتمال إنتاج منتج ذي 
جودة ضمن الموازنة والجدول الزمني المحددين يُقلص بشكل كبير 
(في الواقع» إن الانتباه إلى هذه العوامل لا يضمن نجاحها). 


3-1 إدارة تطوير البرمجيات المورَّعة المراكز 


لقد قمنا بتطوير مجموعة من الممارسات التى نستخدمها فى 
المشاريع التي تتوزع جغرافياً» وذلك بعد معاناة زيلة غناك على 
كثير من حالات التجربة والخطأ. وهذه الممارسات ليست الحل 
السحري» لكننا حاولنا جمع الخبرات الجيدة والسيئة على حدّ سواء 
وتصنيفها في إطار عمل يوفْر طريقة أكثر تنظيماً لإدارة وتنفيذ مشاريع 
تطوير البرمجيات المورّعة المراكز. 


قمنا من خلال هذه الخبرة التجميعية بتحديد العوامل المهمة 
لنجاح مشاريع تطوير البرمجيات الموزّعة المراكزء وصنفنا أفضل 
الممارسات لتوظيف هذه العوامل للحصول على نتائج ناجحة. وقمنا 
بتطوير إطار عملية تقدم أفضل الممارسات المصنفة في عوامل 
النجاح الحاسمة. ويتركز هذا الإطارعلى نموذج البرمجة السريعة 
العالمية الذي يجمع بين الاتجاه نحو عملية تطوير البرمجيات 
المورّعة المراكز وممارسات البرمجيات السريعة. وحين التفكير في 
ممارسات البرمجة السريعة» يُتوقع من القارئ أن يستحضر في ذهنه 
صورة لتطوير البرمجيات المستخدمة أساساً فى بيئات العمل 
المنتظمة. لقد أدركنا أن العديد من ممارسات اللريقة السريعة 
(2002 ,تتتناطاعاء00)» قد تخطت ذلك نحو تحديد المشاكل ذات 
المفهوم المشترك وتطور المشروع. هذا وتكون هذه الممارسات 
قصيرة حين استخدامها فى سياق البرمجة العالمية. وقد حاولنا زيادة 
الجمارهات الشريعة دنا نزم الأمر معط ركه الحناظ على معط 
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المنافع التي تتحقق منها مع قياس طريقة البرمجة في سياق تطوير 
البرمجيات المورّعة المراكز. ويمكن حدوث ذلك فقط عن طريق 
تطوير وتحديد الإعدادات الأساسية والعمليات وآليات العمل وأفضل 
الممارسات التي تسمح بالحصول على أقصى تبادل بين نظام السرعة 
ونظام العملية (2004 ,تعصعنة1 قصة ستطءه8) . 

يرتكز إطار عمل العمليات خاصتنا على النموذج التكراري 
([2006< عاتاة161) للبرمجة مع تعريف واضح للأدوار والمسؤوليات 
وتعريف البنية التحتية لتسهيل التنسيق والتعاون والجوانب الأخرى 
التي تربط الأفكار العامة لنظام عملية تطوير البرمجيات المورّعة 
المراكز بالسرعة. إن فهم معتقدات العمل بكفاءة في بيئة موزعة هو 
ما يُشكل أساس منهجيتنا - كتوزيع العمل على عدة مواقع بأمثل 
طريقة وزيادة وتحسين طرق التواصل بين هذه المواقع وتسهيل 
الوصول إلى الخبراء باستخدام الأدوات والممارسات لتحسين الوعي 
والإدراك خلال هذه المواقع. 


4-1 الملخص والاستنتاجات 

إن عملية تطوير البرمجيات المورّعة المراكز هي عملية صعبة 
بطبيعتها؛ إذ تعترضها مشاكل في التنسيق والدوافع واللحاق بركب 
التقنيات المحدثة والبنى التحتية والعمليات التي قد تسبب توقف 
المشاريع. لكن تطوير البرمجيات الموزعة المراكز حقيقة واقعة 
وظهرت لتدوم,ء لذا علينا أن نتعلم كيفية تنفيذ مثل هذه المشاريع 
بكفاءة ونجاح. 

صف هذا الكتاب كحصيلة سنوات عديدة من الخبرة في مجال 
مشاريع تطوير البرمجيات الموزرّعة المراكز إلى مجموعة من 
الممارسات التي يمكن تطبيقها في مشاريع كبيرة وصغيرة تستخدم 
فرق عمل موزرّعة في مناطق جغرافيّة عديدة. 
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5-1 أسئلة للمناقشة 


1. لاذا تُعتبر إدارة مشاريع تطوير البرمجيات الموزّعة المراكز 
أصعب من إدارة المشاريع المنتظمة؟ 


3 “أي غارشات برعة سريعة اهل تطبيقا: -وأبنا يشكل ديا كفن 
مشاريع تطوير البرمجيات المورّعة المراكز؟ 
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(لفصل الثاني 


عوامل النجاح الحاسمة في تطوير 
البرمجيات الموزعة المراكز 


يعمل جون لدى شركة باس (012]100م002© 845) التى نمت 
وتطورت على مر السنين عن طريق اندماجها مع شركات أخرى حول 
العالم. وترغب شركة باس فى تعزيز المنتجات المتفاوتة من الشركات 
المفردة في خط إنتاج واحد» و برس وير المنتج الجديد 
لتحقيق ذلك. ومع أنه استطاع إنجاح العديد من المشاريع التي 
شكلت تحدياً بالنسبة إليه» غير أنه لم يعمل قط في مشروع يتضمن 
تنسيق جهود فرق البرمجة من عدة مواقع حول العالم. يبدأ جون 
بالتساؤل عن كيفية اختلاف طريقته في العمل في هذا المشروع عن 
إدارة مشروع منتظم في موقع واحد. 

في عصر الاقتصاد العالمي» يجد العديد منا أنفسهم في أوضاع 
وظروف متشابهة لأسباب مختلفة. فأجور العمل منخفضة حالياً فى 
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دول أوروبا الشرقية والبرازيل والهند والصين» وقد يكون هناك توفير 
في التكلفة إذا تم اللجوء إلى مصادر خارجية لتطوير البرمجيات في 
هذه الدول. فقد تتوفر لدى الشركة في مجموعة من التقنيات أو في 
مجال معين » فتحاول استغللال ذلك لجذب الشراكات. ونئحت وطأة 
نقص الموظفين والضغط الذي يتسبب عن ضرورة الالتزام بمواعيد 
في ذات الوقت باستخدام قوى عاملة من دول مختلفة. 

نتناول في هذا الفصل بعض الأمور المتعلقة بمشاريع تطوير 
البرمجيات الموزّعة المراكز ويُبرز العوامل الحرجة والحاسمة لنجاح 
هذه المشاريع. إضافة إلى ما تقدم» يبدأ الفصل بشرح إطار عمل 
عملية إدراك عوامل النجاح هذه. وتشكل المقذمة العامة في هذا 
الفصل خريطة الطريق للتفاصيل التي تتابع في الفصول الآتية. 
1-2 قضايا 


عندما تتعامل الشركات بمشاريع تطوير البرمجيات الموزّعة 
المراكز» لا تقوم بتقويم أثر استخدام فرق العمل الموزرّعة في مناطق 
جغرافية عديدة. وأحد أسباب ذلك أن الحد الذي يعتمد فيه 
الأشخاص الذين يعملون في بيئة عمل منتظمة على التواصل غير 
الفط بوص النسى ال مريت قد إن أل علو وجردهنا 
النوع من التواصل وعدم الأخذ بالحسبان غيابه أمر خطير بلا شك. 
فقد اختبر مؤلفو هذا الكتاب هذا الأثر السلبى فى العديد من 
المشاريع الفاشلة في شركات عديدة متنوعة. 00 

بناء على هذه الخبرات» تم تعريف عدد من العوامل الحاسمة 
لنجاح مشاريع تطوير البرمجيات الموزعة المراكز. وهذه العوامل ذات 
مستوى متقدم باعتراف الجميع» وهي لم تكن وليدة الصدفةء» بل هي 
نقل ملائم للخبرات المتولدة على مدى السنوات. وللمساعدة في 
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تفسير كيفية توظيف عوامل النجاح الحاسمة عملياًء قمنا بتطوير إطار 
عمل لتوضيح العملية التي تجسّد هذه العوامل. ولا يُقصد بذلك 
اقتراح إطار العمل هذا كحل للجميع. إن مبدأ «حجم واحد يلائم 
وإظهار كيفية إدراك هذه العوامل في مشروع تطوير البرمجيات 
المورّعة المراكز. 

2-2 عوامل النجاح الحاسمة 

المورّعة المراكز. ففي حين أن هذه العوامل مفيدة لجميع المشاريع» 
غير أن حالة العمل والضرورة أكثر أهمية عندما تكون المشاريع 
مورّعة فى عدة مناطق جغرافية تختلف فيها المناطق الزمنية وتعمل 
يكون لدى أي منها تاريخ عمل مع الآخرين» إضافة إلى فروقات 
اللغة والثقافة. تهدف هذه العوامل إلى تجسيد الخبرة المكتسبة من 
العديد من هذه المشاريع (وهي بالتالي تكون نظرية جداً). يعتمد 
إدراك هذه العوامل في أي مشروع على أمور كثيرة كالعمليات 
التنظيمية وخصائص فرق العمل والبنى التنظيمية والنظام الذي يجب 
بناؤه. يجب أن ينظر إلى تطبيق عوامل النجاح هذه كاستثمار في 
التخفيف من حدة المخاطرة وضمان الجودة. فى الفصول الباقية من 
هذا الكتاب» سنعطى أمثلة وتوجيهات على كيفية حساب هذه 
العوامل في مشاريعكم. 


1-2-2 الحد من الغموض 
في حين أن الحد من الغموض والالتباس المرتبط بجميع مظاهر 
أي مشروع أمر مرغوب فيه يتم الكشف عن العديد من حالات عدم 
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التأكد والغموض في المشاريع المنتظمة» والتي تنتج من التواصل غير 
الرسمي. لا تتوفر هذه الرفاهية في مشاريع تطوير البرمجيات الموزّعة 
المراكز. فالغموض يقود إلى الافتراضات. ولا تكون هذه الافتراضات 
ظاهرة للعيان بسهولة» وهو ما يؤدي إلى وجود بعض الافتراضات 
المتناقضة لبعض الوقت قبل أن تعبّر عن نفسها كمشاكل. إن ظهور 
مثل هذه المشاكل يتطلب إعادة التخطيط وإعادة التصميم وإعادة 
العمل؛ وتنفيذ هذه الأمور ليس بالأمر السهل في بيئة عمل مورّعة. 
فقد يكون التنسيق بطيئاً وشاقاً وغير فعال. كما إن تأثير وجوب وجود 
أنشطة التتسيق: الكثيفة قد-يسسب تأخيرا طويلا كما يرك فرق العمل 
عاطلين ومحبطين» ويتسبب ذلك بمشاكل في الجودة وقد يتسبب في 
توقف المشروع (أكثر من مرة). 

قد يرتبط الغموض والالتباس بالعمليات التنظيمية» أو 
بالممارسات الإدارية أو متطلبات العمل أو تصميمه. فإذا اجتمعت 
هذه الحالات مع نقص في الخبرة والمعرفة التي يمتلكها أعضاء فريق 
العمل يصبح الوضع أكثر تعقيداً. لذا يتطلب الأمر الكثير من التفكير 
والعمل للاتفاق حول كيفية عمل الفرق المختلفة مع بعضها بعضا 
لضمان استخلاص الهدف المطلوب من المشروع. يجب أن تعرّف 
العمليات قواعد الارتباط بوضوح» كما يجب صياغة متطلبات العمل 
بحيث يسهل فهمها؛ ويجب تطوير الهيكلية وتوسيعها مع الملاحق 
بين النماذج المعرّفة والعناصر المحددة مع بينيات معرّفة جيداً. هذا 
ويجب أن يتم إنشاء رزم العمل للفرق الفردية متضمنةً مهام العمل؛ 
فضلاً عن كل ما تقدم» فحين إجراء التواصل بين الفرق للحصول 
على بعض التوضيح» يجب أن يضمن الشخص ذو العلاقة أن جميع 
إجابات الأسئلة صحيحة ومفهومة. 


إن ما هو واضح لإحدى فرق العمل ذات خلفية وثقافة خاصتي: 
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قد لا يكون بذات الوضوح لفريق آخر. وقد يتطلب الأمر وجود 
آليات للتحقق من فهم مظاهر محددة في المشروع ووجود برامج 
تدريب أو تبديل للأفراد. يجب أن يتم التوظيف بعناية وحذر للموازنة 
بين الخبرات التقنية والمعرفة في مجال العمل والمطلوب. تحكم 
خصائص المشروع مقدار الغموض الذي يمكن التعامل معه إضافة 
إلن. الآلباف المادسمة لتعوين معن الدتر ير فطل سنن[ المفال إذا 
ارتبطت إحدى المنظمات الراعية بعلاقة طويلة الأمد مع فرق العمل 
عن بُعدء ستتأسس على الأرجح ثقافة عمل تسهّل أمور التواصل 
الخاصة بالمشروع إذا ما قورن الأمر بوجود فريقَيْ عمل لم يتقابلا أو 
يعملا مع بعضهما البعض من قبل. 


2-2-2 الحد الأقصى من الاستقرار 

يؤثر عدم الاستقرار في عدد من جوانب المشروع. فعلى سبيل 
المثال» العمليات السريعة (5:0065565 16زع3) هى استجابة للمتطلبات 
غير الواضحة وغير المستقرة. إن من أهم المعتفدارث المرتبطة 
بالعمليات السريعة أنها تسعى جاهدة إلى إنشاء بيئة تستخدم التواصل 
الطارئ وغير الرسمي بأفضل طريقة ممكنة كالبرمجة المزدوجة 
والعمل في نفس المكان ووجود من يمثّل العميل في موقع العمل. 
والفترات البرمجية المكررة القصيرة (1]67211005 +5501 والاجتماعات 
البوبية الشوضعة الفى تنم وقوقاء. إلى عير ذللقة من السيطتي أن 
يكون الاستقرار عاملاً حاسماً في المشاريع الموزّعة» التي تصعب 
فيها مثل هذه الأنواع من التواصل. إن تأثير وجود عوامل عدم 
استقرار في المشروع هو نفس تأثير وجود أمور غامضة غير واضحة 
في المشروع ٠‏ 


ماذا يعنى ذلك؟ يمنا ذلك يعنى أنه يعتمد بدرجة كبيرة على 
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تفاصيل المشروع» لكن قد يعني ذلك وجوب تأخير البدء بمرحلة 
التطوير» فلا يتم البدء بها كما هو الحال في المشاريع المنتظمة 
التقليدية» وذلك لإتاحة الفرصة لاستقرار مواصفات متطلبات العمل 
والتصميم إلى أفضل وضع ممكن. 

در طلبات التغيير (760116515 ©605328) مخاطرة كبيرة فى 
مشاريع تطوير البرهجيات المورّعة المراكز عالنياة إذ يتطلب تفيدها 
وقتاً أطول ب 2,4 مرة من الوقت الذي تتطلبه المشاريع المنتظمة 
(2003 ,ؤناكاء 210 0طة «اعاوط:116). وبناءً على ذلك» لا يمكن التهاون 
في هندسة المتطلبات وهيكلتها بامتياز. 


وقد يعني ذلك تطوير المزيد من النماذج البدائية (65م(10101م) 
وتصميم العديد من نماذج واجهات الاستخدام وتطوير أطر عمل 
مختلفة أو تخصيص بيئات برمجية. هناك العديد من الطرق التي 
يمكن اتباعها لتحقيق الاستقرار في مختلف جوانب المشروع. 
وسنعطي أمثلة ونشرح كيفية تحقيق ذلك لاحقاأ في هذا الكتاب. 


3-2-2 فهم الروابط 

ينطوي الترابط بين المهام على حجم ونوع وتواتر التنسيق 
المطلوب بين المشاركين في مشروع تطوير البرمجيات الموزع. فهي 
مهمة وحاسمة لوضع خطة المشروع وتنفيذه للتعامل مع احتياجات 
عملية التنسيق. وعادةً ما تُعامّل الروابط على أنها «تستدعى العلاقة 
متطقمه12ء* 02115» بين النظم الفرعية التي يتعين توزيعها. ففي حين 
أن مثل هذه العلاقة لا تعنى وجود ترابط». غير أن هناك جوانب 
أخرق يجب أحذها بعين الاعتبار. قمن وتجهة النظر التقنية: .هناله 
الغدود مق العوامع الى .قن تسجلوم اتسين كلى.صبيل المغاله إذا 
كأ عاك متطلب» عب سر نقد يتظلب ذلك تسيقاً بين مع 
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فرق العمل ذات العلاقة بالبرمجة (8هذ0مه) التي يمكن تنفيذها فى 
نفس الوقت؛ أو إذا كانت إحدى الفرق مسؤولة عن تطوير نظام 
فرعي يتطلب خوارزمية معالجة الصورء فقد يتطلب ذلك حاجة ملحة 

إن الجوانب التقنية للمشروع ليست المصدر الوحيد للروابط. إذ 
إن هناك العديد من الروابط المؤقتة التي تنشأ عن التخطيط أو عن 
تقسيم عملية التنفيذ إلى مراحل. فعلى سبيل المثال» قد يتم توزيع 
عملية التنفيذ في مراحل البرمجة أو بواسطة النماذج المكتملة أو 
بواسطة النظم الفرعية التي توجد في مواقع البرمجة المختلفة. وهذا 
الأخير قد يكون مفيداً أكثر من السابق. هذاء وسنقوم بتفصيل كيفية 
تحديد الروابط وأخذها في الحسبان في مشروعك. 


4-2-2 تسهيل عملية التنسيق 


إن استكمال فهم طبيعة المهام المترابطة أمر مهم لتيسير التنسيق 
المنسجم. يجب أن تكون فرق العمل التي تقوم بعملية التنسيق قادرة 
على عمل ذلك بطريقة تتناسب مع الاحتياجات. هناك طرق عديدة 
مختلفة يمكن لفرق العمل استخدامها للتنسيق. ففى حين يعتقد أن 
الست ااه إلا نيه الال درفي اندافي الزاقع اربع من ذلك 
بكثير. فالتواصل هو أحد السبل التي تُستخدم للتنسيق؛ وهناك طرق 
أخرى كتنسيق العمليات والممارسات الإدارية وهيكلية خط الإنتاج 
على سبيل المثال لا الحصر. ويمكن أن يُنظر إلى هذه الخيارات 
باغقارها مفاضلة بين الثققات العامة والتخاطر. متلا إذا طلب من 
شركة برمجيات تصميم وتطوير إطار عمل يحد من خيارات التصميم 
لفرق عمل تعمل عن بُعدء بينما يُفرض على فرق العمل التي تعمل 
عن بُعد التكامل والاندماج مع الهدف الأصلي للفريق» تكون تكلفة 
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بناء إطار العمل كهذا مرتفعة جداً. كما سيحد إطار العمل من الحاجة 
لتوضيح قرارات التصميم. 


من خلال تجربتناء تبين أن مشاريع تطوير البرمجيات المورّعة 
المراكز عالمياً تركز فى الكثير من الحالات على الحد من التكاليف 
هاا امكن» ذلك يفل مدان مكار لى ونان 11 وطق يننا 
يُعطى القليل من الاهتمام إلى الاستثمار في تطوير العمليات وبيئة 
البرمجة التي يمكن أتمتتها لدرجة ماء وبالتالي توجّه جهود التنسيق 
بين فرق العذل المتاركة إلى معن هيف لكو الحاجة واضحة 
داكها هت اليذانة "هذا يتنظبق على متناو الحووة العن بعشل يها 
برنامج ما في بيئة عمل معينة. إذأ من الحكمة اا انع البيعيائت 
النسخ الاحتياطية («ناءاءة0) التي يلجا إليها إذا ما سارت الأمور على 
غير ما يرام. 


5-2-2 الموازنة بين المرونة والتشدد 


يجب أن تكون ممارسات مشاريع تطوير البرمجيات الموزّعة 
المراكز أكثر مرونة وأكثر تشددا من مثيلاتها من المشاريع المنتظمة. 
فغالباً ما يكون أعضاء فرق العمل التي تعمل عن بُعد ذوي خلفيات 
مختلفة ويتعاملون مع عمليات برمجة مختلفة» وهم يختلفون أيضاً 
في مستويات الخبرة والمعرفة في مجال العمل والثقافة» وتتّبع في 
بعض الحالات ممارسات إدارية مختلفة. يجب أن تكون عملية 
البرمجة مرنة بشكل كافٍ لتلائم هذه الفروقات. وقد يعني ذلك إعطاء 
فرق العمل التي تعمل عن بُعد بعض الحرية في اتّباع منهجية داخلية 
للبرمجة أكثر سرعة. 

يجب أن تكون العملية مبنية بطريقة أكثر تنظيماً وثابتة بطريقة 
معينة. ويجب أن تكون صلبة بما فيه الكفاية لضمان دقة تحديد 
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مظاهر المشروع وأن العمليات المتبعة كشبكات الأمن الطبيعية في 
مكانهاء كما يجب ضمان فهم الأآمور الآأخرى كالتعليمات» وأن 
متطلبات العمل قد تحققتء» وأن عمليات إدارة الإعدادات والتهيئة 
معرّفة بشكل كافٍ» وأن إجراءات التكامل والاختبار مناسبة» إلى غير 
ذلك من أمور. هذه الأمور ضرورية لمراقبة تطور المشروع وضمان 
الالتزام بمواعيد التسليم وضمان الجودة. 


5-2 إظار العملية 


المورّعة المراكز. ليس الغرض هنا وصف العملية الدقيقة التى يجب 
أن يتبعها كل مشروع» لكن الهدف هو تعريف المفاهيم التي عرض 
لها في هذا الكتاب بطريقة أسهل وعرض كيفية إدراك عوامل النجاح 
الحاسمة؛ ولتحقيق ذلك يتم وصف إطار عمل متقدم مرفقاً بخطوات 
العمل التي يجب على فرق العمل التابعة للمشروع اتباعها. ولا نقصد 
وجود عملية مناسبة لجميع المشاريع. ففي حين أننا استخدمنا هذه 
العملية عملياًء غير أنها تتطلب تكييفاً واعتماد السياق المعطى. وتم 
توضيح الأنشطة التي يتضمنها إطار العمل كخطوات متتالية تعطي 
عملياً»ء ستكون هذه الخطوات متكررة كثيراً. 

إن الهدف من خطوة هندسة المتطلبات هو كسب فهم جيد 
المفطياة يحنيظ رعزت 'السرء التظلونة ,من :تلك المعطليات بويد 
المتطلبات القيادية (هى المتطلبات المهمة التى لها قيمة فى العمل 
«7721116 ووعصلوتاط» أكثر من غيرها في النظام الذي يتم تطويره). 


نستخدم هندسة المتطلبات التى يحكمها نموذج ومنهجية البرمجة 
المتبعة (2004 200 ,200423 :2003 ,طعةطمونمء8) . التى تستخدم لغة 
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التملجة الموحدة 01/13) لمحديد المتطاباث: لا توفر'لغة التمذحة 
الموحدة أي دليل على كيفية وجوب استخدامها؛ علينا - من خلال 
عمليات البحث ‏ تطوير منهجيات تؤدي قدرة لغة النمذجة الموحدة 
على إضافة معنى للروابط التي تربط بين المتطلبات» وبالتالي تسهيل 
عمدة يقلي الجطانات شن حيف الإتمام والأتساق والعودة يركذلك 
السماح بالتعقب الآلي لنماذج التصميم والاختبار. 


الشكل 1-2: إطار عمل لمشروع تطوير البرمجيات المورّعة المراكز 


تُعتبر هندسة متطلبات العمل التي يحكمها نموذج البرمجة عملية 
تطوير وصيانة منهجية لمتطلبات المنتج التفصيلية والتي تبدأ عندما 
يكتسب المنتج دفعاً كافياً؛ وهناك حاجة مبكرة في المشروع لتطوير 
ذلك من خلال عمل نماذج أولية للمنتج وتحليل العمل في 
سيناريوهات صغيرة (2005 ,[.1ة أع] قصه5) (عسصتلهدهط:(5)01) . 
لاكتشاف المتطلبات ذات العلاقة بالهيكلية الأساسية» وتفاعلاتها مع 
غيرها من متطلبات المشروع ووضع استراتيجيات للتصدي لأي 
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تعارض ناتج » نستخدم تقنية تعرف بالتحليل الشامل 66] 65أذاعم1105) 
(2000 و[لة. 


بالنسبة إلى مشاريع البرمجة الموزّعة في عدة مواقع. توفر 
هندسة المتطلبات التي يحكمها نموذج البرمجة منافع عديدة تساعد 
في التغلب على بعض الأمور المتعلقة بالتواصل والتنسيق والتحكم. 
وتساعد النمذجة المرئية على التواصل والتفاهم بين فرق العمل 
المورّعة. وتوفر الأداة التي تستخدم لتقويم النماذج قياسات حسب 
الطلب لحجم المتطلبات والتقدم في المشروع ودرجة الثبات ومقدار 
ما تمّ إكماله ودرجة الجودة. وعلى نحو أكثر أهمية» يمكن أن توفر 
نماذج لغة النمذجة الموحدة دعماً لعمليات التتبع المؤتمتة؛ كما 
يمكن تتبع المتطلبات المنمذجة قدما ومطابقتها بالتصميم والاختبارات 
أو بشكل رجعي لمطابقتها بمتطلبات السوق وطلبات المساهمين 
وأهداف العدل. قد يساعد ذلك في التحقق من المتطلبات المشمولة 
(أي المتطلبات التي تم تنفيذها في إصدار معين) وتحليل تأثيرها (أي 
ما هو تأثير التغيير في المتطلبات). 


ينصبٌ تركيز خطوة تصميم هيكلية النظام على الحصول على 
فهم تفصيلي للمتطلبات الهيكلية المهمة وإنشاء هيكلية قابلة للتنفيذ. 
وتتعامل العديد من منهجيات البرمجة مع الهيكلية بطريقة غير مباشرة 
أو ضمنية. وتعتمد جودة النظم المبرمجة باستخدام إحدى منهجيات 
البرمجة هذه على مستوى مهارة وخبرة المخطط بشكل كبير. نستخدم 
طرقاً للهيكلة المركزية (2003 ,21.1 :©] 8385) كورش عمل خصائص 
الجودة (0477) والتصميم المحكوم بالخصائص ((81) وطريقة 
التحليل الهيكلي المتبادل (414131). وتوفر هذه الطرق توجيهاً 
منهجياً وصريحاً للمصمم لإنشاء النظم بالجودة المطلوبة. وتتعامل 
طريقة ورش عمل خصائص الجودة مع المساهمين مبكراً في دورة 
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نجياة توضجة النظام الأشرداف معطااف: التقردة الح تقو بدوركنا 
هيكلية النظام. أما طريقة التصميم المحكوم بالخصائص فتستخدم هذه 
الميطاات انيع كني النظام ٠:‏ يما تساعك طريكة “المحليل 
الهيكلي المتبادل المساهمين على فهم التسلسل في المشروع الذي 
يلي الهيكلية التي يتم اعتمادها. 


يُستخدم مدير المشروع وثيقة خصائص المتطلبات وخصائص 
الهيكلية والنموذج لعمل خطة المشروع لتنفيذ المنتج الجديد 
(2002 ,طوتانحة2). ينفذ مدير المشروع تحليلا للمخاطر ويقوم بتعريف 
استراتيجيات المشروع؛ كما يقوم بإعداد خطط للإصدار التزايدي”*) 
(عقةع161 81]هعدمونءعم) وخطة البرمجة المقترحة و التي يصف فيها 
كيفية برمجة المنتج وزمن ذلك. وتستخدم طرق التقويم لتقرير الجهد 
اللازم لبرمجة المنتج والجدولة الزمنية لذلك. 

في خطوة برمجة المنتج» يتم تصميم نماذج البرنامج وتنفيذها 
والاختبار ودمجها مع إصدارات المنتج المتوسطة والتي قد يكون 
بعضها في موقع العميل للاختبار كإصدار بيتا (616256 0612). في 
آخر الأمرء يتم إنتاج خط أساس للمنتج ناضج بما فيه الكفاية للنشر 
في بيئة المستخدمين. 


يتم تنظيم برمجة المنتج للحصول على الحلول المثلى باستخدام 
فرق برمجة صغيرة موزّعة ومتزامنة بواسطة تنظيم مركزي. وتستلم 
فرق البرمجة المورّعة في مناطق مختلفة في العالم خصائص النموذج 
من الفريق المركزي. ويكون كل فريق مسؤولاً عن تصميم وتنفيذ 
واختبار النموذج المصمم؛ هذا ويقود كل فريق مدير التزويد 


() إصدارات متكررة قصيرة تتكون كل منها من الإصدار السابق مضافاً إليه 
خصائص جديدة. 
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(22323861 عناممن5). فى تجربتناء يكون دور المدير المورّد غير 
العاشر). 


تعمل فرق البرمجة على تنفيذ فترات برمجية تكرارية متزايدة 
للنماذج باستخدام أسلوب الاختبار المقدّم آخذين بالحسبان أفضل 
الممارسات التى توفرها منهجيات البرمجة السريعة. وينفذ الاختبار 
لتجربة الواجهات البينية للدموذج الفريق المسؤول عن هيكلية النظام » 
وهذه الاختبارات لذ تتستاغيك في التحقق من النماذج وحسب» بل 
(2002 ,قهوطزز5) . تصمم النماذج باستخدام عيّنات تصميم معروفة 
ويتم مراجعتها بصورة مستمرة للحفاظ على جودتها وصيانتها 
(2004 رتعانهحهط) . 


4-2 مراحل البرمجة والقرارات 

نستخدم لتخطيط المنتج عملية ذات مراحل. وهي كالعملية 
الموحدة العلائقية القياسية (2500655 1[01860] 22602821 10112) تتكون 
من أربع مراحل في دورة حياة العملية البرمجية فصة 198:ه) 
(2005 ,1082ةآ :2002 ,15]8201ا20. المرحلة التحضيرية «متامءهم) 
(6856م هي مرحلة النقطة الحرجة الوهمية التي يتم خلالها الاستقصاء 
عن الحلول المحتملة لتقرير الجدوى من المشروع. ما إن يتم 
الإعلان عن أن المشروع مجدٍء حتى يدخل المشروع مرحلة التطوير 
(©635م 61360126105) . وهى المرحلة ذات المعلم الهيكلى الرئيس 
التي يتم فيها تحديد أولويات المتطلبات وتقرير تلك الأولويات التى 
يجب تنفيذها أولا لأهميتها للهيكلية. وفي نهاية مرحلة التطوير» يتم 
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(©685م دمتاعنةاوهوء) . هذه المرحلة هي مرحلة معلم الإمكانيات 
التشغيلية لأنه في نهايتها يتم توزيع البرمجية في بيئة الإنقاج 
(أع مه كمع ماعن 100م) في مو قع أحد العملاء أو أكثر كإصدار 
بيتا لشرح إمكانياته التشغيلية. حالما يتم تقرير أن البرمجية جاهزة من 
حيث القدرة التشغيلية» تنتقل إلى المرحلة الانتقالية صهماتقصههىن) 
(085م وهي مرحلة حرجة لإصدار المنتج حيث يكون المنتج جاهراً 


فكرة مفيدة: 

إجعل أعضاء الفريق البعيدين جزءاً من الفريق المركزي 
فى سراحل الاولى من المشروع. تتطلب عدد من 
لمتطلبات والأنشطة المرتبطة بالهيكلية تعاونا لنقل 
تخبرات الفعية والييكلية إلى العزق البيدة من 
لمستحسن إشراك أعضاء من الفرق البعيدة في مرحلتي 
لتحضير والتطوير وذلك ليكتسبوا فهماً لمدى المشروع 
وللرؤية الهيكلية. ومن ثم يعود هؤلاء الأعضاء إلى 
مواقعهم حين بدء مرحلة التنفيذ ويتصرفون كخبراء 
محليين. إضافة إلى ذلك» نقترح أن ينتقل هؤلاء الأعضاء 
الرئيسون من فرق العمل البعيدة إلى الموقع المركزي مع 
عائلاتهم. وهذا من شأنه التقليل من مشكلة الحنين إلى 
الوطن التي قد يعانيها الأعضاء وتوفر دعما محلياً حين 
ظهور 1ك «الصدمة الثقافية» . 


تمتد هذه المراحل خلال الفترات البرمجية (5صمناهع)1) 
العديدة» وتؤدي كل فترة برمجية إلى إصدار جزء مكتمل من المنتج 
قابل للتنفيذ. يعتمد عدد الفترات البرمجية وطولها فى المراحل على 
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حجم المشروع. نستخدم تقنيات0*) (متتحمعة) :2004 ,تعط و كطء5) 
(2001 ,016ء86 لصة :2507366 وبناءً على ذلك يتم تقسيم الفترات 
البرمجية في المشاريع الكبيرة إلى فترات شهرية ذات فترات زمنية 
أقصر (5]أضلامة). يتم تخصيص رزم العمل للفرق لكل فترة برمجية 
والتي يتم إكمالها بطريقة متزايدة في حدود الشهر. تسمى هذه 
الفترات المتزايدة بالإصدارات الهندسية (161638565 1108ععماعمة). فى 
لجا الندية البروميية ب شك[ الأسداراف المقدييية الحديدة | مار 
قابلآً للتنفيذ كجزء مكتمل من المنتج. أما في المشاريع الأصغرء قد 
تكون مدة الفترة البرمجية هى نفس ملة الفترة الشهرية» لذا فقد لا 
يكون هذا النوع من التخطيط ضرورياً. 


تفصل بين هذه المراحل فترات اتخاذ قرارات إدارية. يتم 
مراجعة فترة اتخاذ القرار لتقويم نتائج المرحلة الحالية وتقويم المخطط 


تستخدم عمليات التخطيط البرمجي ذي المراحل لتحقيق المنافع 
الآتية : 
© عرض تطور المنتج كبؤرة ابتكار لأفكار جديدة. ويتم التحقق من 
© تتطلب المراحل المبكرة استخدام مصادر أقل من المراحل اللاحقة 
حيث يتطلب الأمر توظيف عدد أكبر من فرق البرمجة لتنفيذ 
واختبار المنتج الجديد. 


() إطار عمل تزايدي تكراري لإدارة العمل المعقد (كبرمجة منتج جديد) وغالباً ما 
تستخدم هذه التقنية في تطوير البرمجيات السريعة. 


67 


© يتم توجيه التواصل بين المبرمجين وموظفي المبيعات في الميدان في 
مراحل مبكرة. لا يشجع موظفو الببعات على بيع الأفكار 
مس ال ار وقد تزيد 
الإفصاح عنها مبكراًء رك سات ميات 
امات الخالة: 


»يتم تحديد أهداف الجودة المرجوة بصورة أفضل» إضافة إلى 
قياسها والسيطرة عليها. قد تستخدم مراجعات فترات اتخاذ 
اللراو كبواباك جمكي لماي ول مدر لها اد نواعم ب عار 
جودة معينة قبل البدء ف في المرحلة التالية من عملية البريحة. 
© تمكن مراجعات فترات 500 
اتروع بو العكم با لكل متتروح ولكان مرغلة من سراح 
فإذا ما كان أحد المنتجات واعداً من الناحية التسويقية ولكن 
برمحته تحتاج إلى استثمارات غير متوقعة» يتم تعديل ميزانية 
السنة المالية أو يتم التبادل بين المشاريع. 
© يمكن إيقاف المشاريع غير الواعدة. تساعد المراحل وفترات اتخاذ 
القرار الإدارة على تقرير كيفية الاستمرار الأفضل في المشاريع 
المنتفيلية وموازنة المحافظ المالية المتسحاتة» 
قد تتكون عملية تطوير منتج جديد من بعض التحسينات 
المضافة على المنتج الحالي ويتم تسويقها كإصدار جديد أو نسخة 
مُعَدلة: حدورنة أو منتج جديد ضمن قطاع سوق موجودهء أو كخط 
إنتاج جديد. يركز هذا الكتاب على المبادرات الجديدة حيث يكون 
هناك هيكلية لبرمجية جديدة أو معدلة لتنفيذ المنتج. وبناة على ذلك» 
لن تذكر الحالاات التي يتم فيها إضافة خصائص جديدة ثانوية لمنتج 
متوفر وله هيكلية. في هذه الحالة» تقوم الشركات عادة بإعداد خطة 
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إصدار تزايدية» ويتم عمل التحسينات إلى أن يتم إطلاق النسخة 
الجديدة من المنتج إلى الميدان. يمكن أن تستخدم المنهجيات 
المقسمة إلى مراحل لإضافة الوظائف الكبرى للمنتج حيث يتم 
الاستثمار فيها بالتوازي مع تعريف متطلبات الإصدارات المستقبلية 
التالية للمنتج الذي يتم تطويره حالياً. 

نشدد في هذا الكتاب على المرحلة المبكرة من مراحل عملية 
تطوير منتج برمجي. فإذا ما تمت عمليات تحليل المتطلبات وتصميم 
هيكلية النظام ووضع خطة المشروع بصورة جيدة خلال المراحل 
الأولى من المشروع» فمن المحتمل أن تتم برمجة المنتج حسب 
نطاق المشروع (56086) والجدول الزمني والميزانية المخصصة ما لو 
تم تخطي هذه الأنشطة أو تنفيذها تنفيذاً هزيلاً. ومن ناحية أخرى» 
لا يتم إكمال هذه الأنشطة بصورة تامة أبدأء وغالباً ما تُترك بعض 
الأمور غير المكتملة إلى المراحل الأخيرة من عملية البرمجة. وعليه 
يتم توفير مجموعة من المبادئ التوجيهية والتوجيهات العامة والنصائح 
لإدارة المراحل المبكرة من عملية تطوير المنتج البرمجي بكفاءة. 

يوضح الشكل 22 مثالاً على عملية تخطيط منتج ذات مراحل. 
أما أنواع القرارات الإدارية (ق) في المثال» فهي 


0 موسج ياه 
مرحلة قرار- ق1 23 
الشكل 2-2: مثال على عملية تخطيط المنتج ذات المراحل 


ق1: قرار بدء البحث عن (منتج أو تقنية أو سوق) للمنتج 
الجديد أو المنتجات الجديدة. 
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© ق2: قرار بدء عملية تحديد المتطلبات وتحليلها وبدء تصميم 
هيكلية النظام المتقدم. 

© ق3: قرار بدء البرمجة. يتم مراجعة خطة المشروع المقترحة في 
هذا الاجتماع لتحديد مجال العمل والجدول الزمنى والاستثمار 
المطلوب لبناء المنتتج حسب المتطلبات والهيكلية المعروفة ضمن 
مرحلة التطوير. 

© ق4: قرار إطلاق المنتج في السوق لاستعمال العملاء. وقد 
الإعلان عن المنتج في الميدان قبل الانتهاء من برمحته. 

© ق5: قرار الأفول أو إخراج المنتج من السوق. وقد تضيف 
بعض الشركات مرحلة قرار متوسطة يتم خلالها تقرير متى 
سيتم التوقف عن بيع ذلك المنتج لعملاء جدد» ومتى سيتم 
التوقف عن صيانة المنتج المتوفر لدى بعض العملاء. 


5-2 الملخص والاستنتاجات 

حددنا في هذا الفصل الأمور المتعلقة بمشاريع تطوير 
البرمجيات الموزّعة المراكز وعرض العوامل التي تعتبر حاسمة لنجاح 
هذا النوع من المشاريع. كما تم شرح إطار العمل لتطوير البرمجيات 
التي يعمل فيها فرق عمل مورّعة التي تفعل عوامل النجاح الحاسمة 
في عنونة بعض القضايا المرتبطة بمشاريع تطوير البرمجيات الموزعة 
المراكز. إضافة إلى شرح إطار العمل الإداري لتقويم المرحلة الحالية 
ومدة البودلة الفا 


6-2 أسئلة للمناقشة 


1. أذكر بعض الفروق المهمة بين مشاريع تطوير البريجيات 
المتتظمة في موقع واحد والمشاريع الموزّعة في عدة مناطق. 


00 


أذكر بعض الاستراتيجيات المستخدمة لإدارة هذه الفروق. 

2 برّر سبب كون هندسة المتطلبات المحكومة بمنهجية البرمجة 
متفوقة على هندسة المتطلبات القائمة على النصوص. لاذا تعتقد 
أنه من المهم بصفة خاصة توزيع مشاريع تطوير البرمجيات؟ 

3. ما أهمية أساليب الهيكلية المركزية لهيكلية النظام ولوضع خطة 
المشروع؟ 


4. تعتبر مراحل القرارات المختلفة في بداية ونهاية مراحل تطوير 
البرمجية بمثابة بوابات الجودة. ماذا تفهم من هذه العبارة؟ 


المراجع 
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الفصل الثالكت 


هندسة متطلبات النظام 


وجد ألبيرتو وهو مدير مشروع (8485)» أن مشروعه في مأزق 
أليم؛ حيث كان أعضاء فريق الاختبار يحصلون على جزيئات من 
البرمجية شهريا لاختبارها من دون معرفة الوظائف التي تم تنفيذها؛ 
ولم يكن واضحاً بالنسبة إليه (أو لأي شخص آخر) ما الذي ستسلمه 
فرق البرمجة في الفترات البرمجية التكرارية» وكان المشروع يبتعد 
أكثر وأكثر عن الجدول الزمني المقرر. 

علاوةٌ على ذلك» أصبح زميله سوبوء الذي يعمل في فريق 
هندسة المتطلبات» عاجزا بوجود عدد كبير من المتطلبات الحالية 
الموجودة فى قاعدة بيانات كاليبر (02]86356 2أو6زله0)» بل إنه كان 
معزقاً مايه كبر نزم المتطاياف الجدية القن فى إعناتهاة ولان عملي 
برمجة المنتج مستمرة منذ ست سنوات ولا يبدو في الأفق نهاية لهاء 
كان من الصعب تتبع كيفية تغيّر تصميم النظام مع الوقت ليلائم 
جميع المتطلبات الجديدة الناشئة. 

إن السبب الجذري للمأزق الذي وقع فيه كل من ألبيرتو وسوبو 
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هو تجمع عدد كبير من الأنشطة التي انحرفت عن مسارها. وفي ظل 
غياب عملية مناسبة لهندسة المتطلبات لمشروع تطوير البرمجيات 
الموزرّعة المراكزء سيكون من الصعب تجنّبٍ مثل هذا الوضع. 
وسنركز في هذا الفصل وفي الفصل التالي على هندسة المتطلبات 
بشكل أو بآخر. 

نركز فى هذا الفصل على عملية هندسة البرمجيات الوظيفية 
والقضايا المرتبطة بتطوير البرمجيات الموزّعة المراكز ومنهجيتنا في 
التعامل مع هذه القضايا. أما في ما يتعلق بدعم عامل النجاح الحاسم 
«الحد من الغموض والالتباس»» فيركز نهجنا تركيزا كبيراً على 
توضيح جعدا من المتطلبات وتوفير تتبع لتحديد مدى تغطية 
المتطلبات وتأثير التغيير الذي يطرأ عليها. ويُناقش في الفصل الرابع 
كيفية تعريف وإدارة المتطلبات المهمة بالنسبة إلى الهيكلية وكيفية 
ربطها بالمتطلبات الوظيفية وتضمينها في سياق مشروع تطوير 
البرمجيات المورّعة المراكز. 


1-3 تمهيد 

كما هو الحال بالنسبة إلى الجوانب الأخرى لتطوير البرمجيات» 
فإن الأمور المتعلقة بهندسة المتطلبات التي قد تعاني منها مشاريع تطوير 
البرمجيات المورّعة المراكز قد توجد في المشاريع المنتظمة أيضاً. ولكن 
احتمالية وتأثير هذه الأمور لا يكون نفسه في مشاريع تطوير البرمجيات 
المورّعة المراكز والمشاريع المنتظمة. فعلى سبيل المثال» قد تكون إدارة 
التغيير معضلةً صعبة الحل في جميع المشاريع ؛ ففي مشاريع تطوير 
البرمجيات المورّعة المراكز من الصعب إجراء تحليل دقيق لتأثير التغيير 
فى المتطلبات بسبب الرؤية المحدودة للأنشطة التفصيلية لفرق البرمجة 
الحو عط غرة اطي و الميينة انف تعب نكا مجان خودي عزنا 
للبرمجة 5 التي يجب تسليمها. 
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وكما هو الحال في جميع المشاريع» تعتمد الأنشطة الأخرى 
(كعمليات التصميم والاختبار والتخطيط) على عملية هندسة 
المتطلبات. وهذا يُلقى عبئاً إضافياً على جهود هندسة المتطلبات لأن 
العمليات أكثر تعقيداً في مشاريع تطوير البرمجيات الموزّعة المراكزء 
وذلك لتنفيذ هذه الأنشطة بالطريقة الملائمة. ويّناقش في هذا القسم 
هذه القضايا بمزيد من التفصيل» ثم يُتابع في الفصل شرح المنهجية 
المتبعة للتعامل مع هذه المشكلات. 


1-1-3 إدارة التغيير 
إدارة التغيير هي من أكثر الأمور صعوبة حتى في أفضل 
الظروف. نتحدث فى هندسة التغيير (على الأقل فى هذا السياق) عن 
إدارة التأثير المواعت للتغيير فى المتطلبات. تلصيفنة عملية إدارة 
التغيير ما يلى: ْ 
#بقايل العانتر نا نعي كلد العقيير 4 طاح التبورل عا افيه 
دقيق للأنشطة التي ستتأثر بالتغيير (والمهام المسندة لفرق 
العم ): 
© تحديث الأعمال المرتبطة: يجب تحديث المتطلبات والتصاميم 
المرتبطة. 
© إعادة التخطيط: إذا تم قبول التغييرء يلزم تعديل الجدول 
الزمني للمشروع. 
كنا ذكر سابقا »من المتعنين: التمصتول قلق قناصيل وامنعة 
للأنشطة التي تقوم بها فرق العمل العديدة في مشاريع تطوير 
البرمجيات الموزّعة المراكز. ففي ظل غياب التتبع الواضح بين 
المتطلبات والتصميم» قد يكون تحديد الفرق المتأثرة بتغيير المتطلبات 
أمراً صعباً. في مشاريع تطوير البرمجيات الموزّعة المراكز» لا تكون 
الاجتماعات التي تعقد لوضع التصاميم ومراجعة المشروع سهلة أو 
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ذات كفاءة نظراً إلى عدم توفر أعضاء فريق العمل في موقع واحد. 

هذا ويجب وجود عملية تتبع واضحة بين المتطلبات وخطة 
المشروع. في بيئة العمل السريعة التقليدية» تكون العلاقة بين 
المتطلبات والخطة ديناميكية. فعندما نقوم بتعديل وضبط الخطة 
عملية تحليل التأثير وإعادة التخطيط. سنناقش كيفية عمل ذلك فى 
القسم: الآتي: 

2-1-3 ضمان الجودة 

إن الأنشطة المتعلقة بضمان الجودة مهمة جداً في مشاريع 
تطوير البرمجيات الموزّعة المراكز. ومن المهم الحصول على ردود 
الأفعال والانطباعات الدقيقة عن تطور عمل فرق العمل المختلفة 
وعن المشروع كاملا بصورة دورية. ومن الأمور التي قد تكون صعبة 
تنفيذها بالتوازي (أو تقريباً بالتوازي) مع عملية بناء النظام. تدعو 
المنهجيات البرمجية السريعة (5عطعةه*مم2 مانعة) إلى أن ينفذ 
المبرمجون اختبارات 1650 16هنا) كجزء من عمليات البرمجة (مثال: 
كما في منهجية البرمجة التي تحكمها الاختبارات). ندعو إلى الالتزام 
بهذا الإجراء أيضاًء لكن المنهجيات البرمجية السريعة لا تعالج قضايا 
التكامل أو اختبار النظام المتقاطع بين الفرق. لقد وجدنا أن هذا أمر 
خطير في مشاريع تطوير البرمجيات المورّعة المراكز. فلتتمكن من 
ومتوقعة من فرق البرمجة في كل فترة برمجية. يساعد هذا في ضمان 
أن المبرمجين متفقون ومنتجون ويحصلون على الدعم اللازم ليكونوا 
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3-1-3 أثر هندسة المتطلبات فى العمليات المترابطة 
والاختبار بطريقة ملائمة في مشاريع تطوير البرمجيات الموزّعة 
المراكز» نحتاج إن عملية هندسة المتطلبات التي تدعم هذه الجهود. 
تجعدق .اوم يجب تتبع مخرجات هذه العمليات؛ يجب أن يفذ أي 
تغيير يحصل على إحدى هذه المخرجات بسهولة على أساس أنه 
تعديل غلن اللمترعاته الأحرق: .فى خالة البيزقق المحروضة سابقاء 
لو توفرت هذه العملية لحلت معظم مشاكله. قد يعني ذلك المزيد 
من التشدد (كما هو متوقع في منهجية البرمجة الانحدارية 
1811 غير أن ذلك غير صحيح. وسنناقش هذا بمزيد من 
التنفصيل في الفصل المخصص لعملية وضع خطة المشروع (انظر 
الفصل السابع من هذا الكتاب). 

2-3 عملية هندسة المتطلبات 

تم التطرق في القسم السابق إلى أهمية المتابعة في مشاريع 
تطوير البرمجيات الموزّعة المراكز. وتعتمد منهجيتنا في الحفاظ على 
المتابعة على إنشاء نماذج للمتطلبات والتصميم في لغة النمذجة 
الموحدة. إضافة إلى ذلك» نقوم بتحليل المتطلبات بتسلسل هرمي 
بدءاً من الخصائص الوظيفية (6861:65) إلى المتطلبات التفصيلية 
لتسهيل المطابقة بين المتطلبات وخطة المشروع. كما نعمل على 
تكوين حالات الاختبار (68565 أ65ا) من نموذج المتطلبات مباشرة 


(انظر الشكل 1-3). 
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أهداف العمل لدم 


الشكل 1-3: مخطط عمل لهندسة المتطلبات 


نشرح في هذا القسم منهجيتنا لتحديد المتطلبات وتوثيقها 
والمتتخظلانة والمدوجات الفرطةالعرلية :كينا تنافش أرقا كيقية 
تنفيذ هذه العملية أثناء مراحل دورة حياة البرمجية. 

1-2-3 تحديد المتطلبات 

قبل بدء هذا النشاط» يجب تحديد رؤية المنتج أو هدف 
السوق. يجب أن يكون هناك تعريف منطقي لسبب قيام الشركة بإنتاج 
هذا المنتج» والغرض الذي سيُستخدم المنتج من أجلهء وما هو 
السوق المستهدف. إن عدم توفر خارطة طريق صلبة تعرّف قطاعات 
السوق المستهدفة (فقد يكون مفاجئاً وجود فكرة عامة واحدة فقط 
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غرن الأسواق والمناظئ الميضيدفة): كرون عن الضعية عمليا تتعديد 
المستخدمين والعناصر التي سيتم التغاضي عنهاء وسيتم وضع 
الافتراضات» وسيتم بذل الكثير من الجهد في المجالات غير 
المرغوب بها أو المطلوبة. 

نقوم بإجراء عملية تحديد المتطلبات أثناء الاجتماعات المجدوّلة 
التي تهدف إلى استخلاص المعرفة الميدانية من الخبراء وتعريف 
الخصائص والميزات التي يتضمنها منظور المشروع وتلك التي لا 
يتضمنهاء وتوثيق الميزات في نموذج ذي منطقية وتنظيم متقدم. 

إن المُخرج الأساسي لعملية تحديد المتطلبات هو نموذج 
للمتطلبات على مستوى الخصائص. لا نستهلك الوقت أثناء 
اجتماعات تحديد المتطلبات في مناقشة النموذج بالتفصيل وإكمالهء 
بل نتأكد من أننا نحدد أهم الخصائص ونقوم بتنظيم النموذج بحيث 
يتم إكمال التفاصيل في ما بعد. وعندما تصبح هذه النماذج أكثر 
تعقيداًء يصبح التنظيم أكثر أهمية. وكما هو الحال في التصميم 
المعمّد. من غير المألوف إجراء إعادة العمل (:268660) وإعادة 
التفكير في تنظيم النموذج نفسه لتعزيز المتوالية المنطقية أثناء إنجاز 
أنشطة تحديد المتطلبات. إن استغراق الوقت والتفكير في تنظيم 
المتطلبات نفسها سيوفر الوقت على المدى الطويلء» إذ سيكون 
نموذج التنظيم الضعيف غير عملي وصعب الاستخدام. 


1-1-2-3 المشاركون 

يوضح الجدول 1-3 المشاركين فى عملية تحديد متطلبات 
فكرة مفيدة: 

إجعل قادة فرق العمل التي تعمل عن بعد يشاركون في 


51 


عملية تحديد المتطلبات. عادة ما يستغرق الأمر وقتاً 
ويدخل في ذلك الوقت المستغرق في نقل المعرفة في 
مجال العمل. تصبح عملية نقل المعرفة أكثر سهولة حين 
حضور مندوبين عن فرق العمل التي تعمل عن بُعد في 
اجتماعات تحديد المتطلبات. وقد يساعد ذلك فى تطوير 


الالتباس لاحقاً. 


الجدول 1-3: المشاركون فى عملية تحديد المتطلبات 


الوظيفة 


المسؤولية 


مهندس المتطلبات 15601116126115) تحديد المتطلبات في النموذج. 


(اععماعمء 


المعاون (111]2]01ع3]) 


خبراء مجال العمل 


مديرو المشروع 


تنسيق اجتماعات تحديد المتطلبات والتأكد من 
استمرارية وتيرة واتجاه الاجتماع لا تزال مثمرة. كما 
يقوم المعاون بتسجيل الأسئلة والقضايا والمتطلبات 
المرتبطة بالهيكلية والأمور الأخرى على اللوح. 
يمثل هؤلاء الخبراء دور المستخدمين الذين 
سيعملون على النظام ويشرحون الخصائص 
يقوم مديرو المشروع بتحديد منظور المشروع 
المشروع بعد تحديد خصائص المشروع المتقدمة. 
المصمم يمثل فريق تصميم هيكلية المشروع» 
ويجب أن يساهم في أنشطة هندسة المتطلبات. أما 
فريق هندسة المتطلبات في فريق التصميم. 
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2-2-3 النمذجة 
نوضح في هذا القسم التنظيم الموصى به لنموذج المتطلبات 
الذي يوجّه القضايا التي تم تحديدها في الأقسام الافتتاحية من هذا 
الفصل. نقوم بنمذجة المتطلبات بلغة النمذجة الموحدة 4ه] 80001) 
(2004 ,011 :2005 ,[.81. ففى حين قد يتحمس بعضهم لاستخدام 
لغة النمذجة الموحدة أو قد يعارضونه (لمبررات منطقية)» وجدنا أن 
هذه منهجية فعّالة نظراً إلى مستوى دعم الأدوات والقدرة على إدراج 
الوصف النصي والمزج بين التنظيم والمرونة. ونقوم أساسا بنمذجة 
المتطلبات كمجموعة من حالات الاستخدام التي تم تحليلها من 
النظام الأساسي والمتطلبات التفصيلية الخاصة بالنظم الفرعية 
(20043 ,2003 ,طاعةطمة:ة8) . وتتكون عملية تحليل المستوى الأول 
من الخصائص والمزايا ذات المستوى الأعلى التي تتوزع إلى 
خصائص ومزايا فرعية (استخلاص حالات الاستخدام). وفي نهاية 
المطاف. يتم تحليل الخصائص إلى حالات استخدام (حالات 
الاستخدام الواقعية). وقد وجدنا أن هذه المنهجية توفر العديد من 
الفوائد (2004 بطع ةطمعمء8)» منها : 
© أن نموذج لغة النمذجة الموحدة أسهل من النص الحر من حيث 
التصفح والفهم. 
© هذا النموذج هو بمثابة خطة عمل مشتركة للاتصال بين 
المشاركين في المشروع. 
#ايمكن التحقق اليا من الاتسباق والاكهال والععليل لفان 
ا لحودة. 
© يمكن استخدامه لإنشاء متطلبات النظام والاختبار وخطط 
المشروع بطريقة شبه آلية. 
تبدأ عملية النمذجة بمخطط بياني لسياق النظام» يبين النظام 
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وكافة الجهات الخارجية التي ترتبط به. يظهر النظام كحالة استخدام 
نظرية ويستخدم بمثابة نقطة واحدة للإدخال في نموذج المتطلبات. إن 
حالة الاستخدام النظرية هى صقل تدريجى لإنتاج حالاات الاستخدام 
الواقعية. يُظهر الشكل 2-3 عملية النمذجة لنظام معلومات صحية 
(1115) تمّت برمجته لشبكة الصحة التكاملية (11127). 


تيون ب 


55 يتضمز 5 ل يتضمن >> 


31 3 
م6 )و << يتضمن >> << يتضمن >> 


الشكل 2-3: متطلبات نظام المعلومات الصحية (أ) سياق النظام (ب) 
الخصائص الأساسية (ج) الخصائص الجزئية (د) حالات الاستخدام الواقعية 
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قد تم تبسيط المخطط البياني عن قصد بسبب محدودية مساحة 
الصفحة. أما في الواقع» فسيكون هناك المئات من الخصائص 
والآلاف من حالات الاستخدام الواقعية. وبناء على ذلك» سيكون 
هناك العديد من المستويات الهرمية. 


إن حالات الاستخدام الواقعية هي خدمات يجب توفرها في 
نظام المعلومات الصحية» وهي بالتالي تمثل المتطلبات التفصيلية 
للنظام. يمكن استخلاص هذه المتطلبات آلياً من النموذج الموضح 
في الشكل 3-3 وهو بمثابة مدخل لخطة المشروع. 

في نهاية عملية النمذجة (قد يزعم الكثيرون أن هذه العملية لا 
تنتهي أبداً)» سيظهر إلى حيّز الوجود نموذجاً لمتطلبات النظام. 
نستخدم النموذج للحفاظ على عملية متابعة التصميم وخطة المشروع. 
وسيتم مناقشة ذلك بمزيد من التفصيل في فصل «عملية التخطيط» 
(انظر الفصل السابع من هذا الكتاب)؛ لكن عندما تقوم بتقويم 
المشروع ووضع خطته.» عليك أن تكون قادراً على وضع قائمة 
بالوحدات اللازمة لمجموعة محددة من خصائص وميزات البرنامج. 
ويمكن إنجاز ذلك عن طريق رسم المتطلبات التفصيلية للميزة 
والبرامج المرتبطة بها والتي ستتحقق فيها جميع المتطلبات. إضافةً 
عمليات البرمجة على فترات قصيرة شهرية. كان بإمكان ألبرتو وسوبو 
التخفيف من مشاكلهما إلى حدٍ معقول لو أنهما استخدما هذه الطريقة 
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الشكل 3-3: استخلاص متطلبات النظام من النموذج 


محاسية المرضى 
إدارة شؤون المرضى 
إدارة الحالاث المرضية 
إدارة الزيارات 
إدخال المريض 
إخراج المريض 


إدارة شؤون 
المرضى 


فكرة مفيدة: 

قم بإعاداة لجودج للمتطلبات باستخدام طريقة «البحث 
التوسعى أوله0 أومة طالمعطط . 

غالباً ما يكمن الغموض في التفاصيل. فإذا ما حاولت 
نمذجة المتطلبات باستخدام طريقة «البحث بطريقة التعمق 
أولخم** فتك يدوق الكرية من الرقك ف مدافش: 
التفاصيل قبل أن يصبح النموذج ثابتاً ومستقراً. إضافة إلى 
ذلك فإن الأمر يتطلب بعض الوقت قبل تجهيز النموذج 
المتقدم كمادة إدخال للمصممين. من الأهمية بمكان 
وجود تبادل دائم بين فريقي إعداد الهيكلية وإعداد 
المتطلبات. إن عرض الخصائص المتقدمة مبكراً لفرق 
إعداد الهيكلية مع التحسين المتعاقب يساعد على تسهيل 
عملية التبادل هذه. 


1-2-2-3 المشاركون 


تبدأ عملية النمذجة أثناء اجتماعات تحديد المتطلبات (الجدول 
2-3). أثناء ذلك» يتم وضع خصائص النظام في نموذج وتحليلها إلى 
خصائص فرعية. يتم التركيز على تنظيم هذه المتطلبات بطرق صحيحة 
وتحديد المشاركين الذين سيتعاملون بها. يتم لاحما تفصيل المتطلبات 


() طريقة متبعة فى نظرية المخططات ([2601 1 طمهمع)» وهى خوارزمية للبحث» 
تبدأ من العقدة الجذرية ثم تنتقل إلى العقد المجاورة. ثم لكل واحد من تلك العقد الأكثر 
قرباً. تستكشف فروعها المجاورة غير المستكشفة» وهلم جراً إلى أن يتم الوصول إلى الهدف» 
والشكل 3-3 مثال على ذلك. 


في عقدة الجذر (حيث يتم اختيار عقدة كجذر في حالة الرسم البياني) ثم تتحرى البحث عن 
طول كل فرع إلى أبعد عقدة ممكنة قبل التراجع. 
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عن طريق تحليل الخصائص الفرعية إلى حالات استخدام واقعية 
وإضافة مخططات الحالة والنشاط والتفاعلات ما بينها. يقوم مهندس 
المتطلبات بإعداد النماذج أثناء تنفيذ عمليات التحليل. وغالبا ما يوجد 
خبير في مجال العمل المطلوب تنفيذه (على الرغم من أنه قد تكون 
هناك أوقات يعمل فيها مهندس المتطلبات على وضع مسودة 
لمفاهيمهم» وذلك بهدف مراجعتها مع الخبير لاحقا). هذه القائمة التي 
تتضمن الأشخاص هي قائمة أقصى قائمة يمكن وضعهاء لكنها ستتغير 
بناءة على نوع العمل المحدد الذي يتم إنجازه ومستوى المعرفة التي 
يتطلب من مهندس المتطلبات اكتسابها وبنية فريق العمل. 
الجدول 2-3: المشاركون في عملية نمذجة متطلبات النظام 


الوظيفة المسؤولية 

مهندس المتطلبات 560]101156126115) تحديد المتطلبات في النموذج. 

(1عع2اعمء 

(واتاعمعء النظام وتفصيل كيفية استخدامه. 

مديرو المنتج أع1ل10م) يقوم مديرو المنتج بتعريف مدى المشروع. عادة 

(5861:5 112112 ما يضطلعون بمهام في المشروع عند تعريف 
الخصائص المتقدمة. 


يشارك في عملية هندسة المتطلبات. الاحتمالية 
الأخرى هو أن يكون أحد مهندسي النظام (أو 
أكثر) عضواً في فريق تصميم هيكلية النظام. 
3-2-3 مراجعة متطلبات النظام 
قد يصبح نموذج متطلبات النظام غير عملي أحياناً ويبصعب 
فهمهء» وقد يظهر فيه تعارض في المتطلبات. لهذه الأسباب» تقوم 
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بمراجعة المتطلبات وتحليلها وإعادتها نظراً إلى توقر الإدراك المشترك 
والنماذج القابلة للاستخدام. أصبح استخدام الآدوات أمرأ حاسما 
لإدارة التغيير في المتطلبات. فعندما تقوم بإعادة صياغة النموذج وإعادة 
تكوين المتطلبات» فإنك لا ترغب في إضعاف خطة المشروع أو أن 
تخفض من درجة تتبع التصميم وإلا تبعثرت العملية. 

تمكننا الطريقة التي نستخدمها لإنشاء نموذج المتطلبات من عمل 
بعض التحليل (التركيبى) اليا (20046 ,داء866068). يمكننا التحقق من 
إكمال النموذج والتأكد من عدم انتهاك القواعد العديدة (مثلاً» الروابط 
التكرارية)» إلى غير ذلك. يجب أن ينفذ التحليل الدلالى يدويا 
أشخاص لديهم معرفة بالمتطلبات ومجال العمل. نقوم بعقد الجعماات 
مراجعة دورية لإنجاز النوع الأخير من التحليل. ويجب أن يلتقي في 
هذه الاجتماعات الأشخاص الذين اشتركوا في عملية تحليل المتطلبات 
إضافة إلى المساهمين الذين لم يشاركوا بشكل مباشر. ولاجتماعات 
المراجعة هذه ثلاثة أهداف هي: (1) ضمان فهم المتطلبات وتفسيرها 
في النموذج بالشكل الصحيح, (2) التحقق من أن نموذج المتطلبات 
مفهوم ومنطقي ومن أن الذين يحتاجون لفهمه يستطيعون قراءته 
بسهولة؛ (3) وإجراء المزيد من التحليل للمتطلبات. وقد وجدنا أن 
أفضل طريقة لفهم ومعرفة المتطلبات هي المشاركة بطريقة ما في 
الاجتماعات الخاصة بمتطلبات النظام. ففي حين أن مشاركة الجميع 
في أنشطة هندسة المتطلبات أمر غير عملي» غير أنه من المفيد مشاركة 
خبراء مجال العمل والمصممين ومصممي هيكلية النظام ومديري 
التزويد في عملية مراجعة المتطلبات. 


1-3-2-3 المشاركون 


يبين الجدول 3-3 أعضاء فريق العمل والمساهمين الذين 
يشاركون في مراجعة متطلبات النظام. تشير خبراتنا إلى أنه يمكن 
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مراجعة أربعة إلى عشرة متطلبات فى الساعة أثناء اجتماعات مراجعة 


الجدول 3-3: المشاركون في عملية مراجعة متطلبات النظام 


الوظيفة المسؤولية 

مهندسو المتطلبات تحديد المتطلبات في النموذج. 

خبراء مجال العمل يمثلون وجهة نظر المستخدمين ويصفون خصائص 
النظام وتفصيل كيفية استخدامه. 

مديرو المنتج يقوم مديرو المنتج بتعريف مدى المشروع. عادة 
ما يضطلعون بمهام في المشروع عند تعريف 
الخصائص المتقدمة. 

مصممو هيكلية النظام (31012116615) ١‏ شخص ينوب عن فريق تصميم هيكلية النظام 
يشارك في عملية هندسة المتطلبات. تكمن أهمية 
وجود المصمم في الاجتماع في أن المتطلبات 
تصبح مألوفة له» كما إنه يستطيع تحديد 

لمتطلبات التي ستؤثر في هيكلية النظام. 

مصممو النظام (065182615 معاذنزة)2 يجب أن يدرك المصممون الذين يقومون بإعداد 

لتصميم التفصيلي ماهية المتطلبات بشكل 

أساسي. وجلسات مراجعة المتطلبات طريقة جيدة 

00 

لمتطلبات. 


مديرو التزويد وهم الخط الدفاعي الأول لفرق البرمجة. يجب أن 
يتفق المديرون مع بقية الأفراد العاملين في 
المشروع في ما يخص المتطلبات وهيكلية النظام 
والتصميم التفصيلي. إن اشتراك مديري التزويد في 
اجتماعات مراجعة متطلبات النظام طريقة جيدة 
ليسهل فهمهم لها. 


5290 


3-3 الأدوات 

من المهم استخدام بنية تحتية للأدوات مع الأخذ بعين الاعتبار 
مدى صعوبة الحفاظ على الاتساق بين نموذج المتطلبات والتصميم 
وخطة المشروع أثناء عملية إعادة صياغة نموذج ضخم معقد. نواجه 
وقتاً عصيباً في وصف البنى التحتية المحددة في ظل عالم الأدوات 
دائم التغير (وهذا خارج مجال هذا الكتاب). ومع ذلك» يتوجب 
ضمان وجود بعض الطرق الأوتوماتيكية ل: 

© إعداد توثيق مقروء ومفهوم من نموذج المتطلبات. 

© تنفيذ تتبع ذي اتجاهين بين قاعدة بيانات المتطلبات والنموذج. 

© تنفيذ التتبع بين نموذج المتطلبات وخطة المشروع (غالباً ما يكون 

ذلك من خلال التصميم). 

إضافة إلى ما تقدم. ننصح بشدة عمل نماذج بدائية للبنى 
التحتية المقترحة إذا لم يكن ذلك متوفراً أصلاً. ولم نختبر إلى الآن 
أداة تتكامل فيها الجهود ليكون أداؤها على النحو المعلن عنه. 
4-3 المرحلة 

هناك ثمة تكامل بين العمليات الفرعية التى تحدث بصورة 
تكرارية وقد تكون معقدة. تفرض عملية تحديد اقل دورة حياة 
البرمجية قيوداً محددة على مخرجات الأنشطة بناءً على موقعك فى 
دورة حياة النظام. ا 

كما ناقشنا سابقاً (وستتم مناقشته لاحقاً) في هذا الكتاب» فإننا 
معنيون بالدرجة الأولى في المرحلة التحضيرية بوضع مفهوم 
للعمليات المتقدمة والخروج بمحاولات متقدمة وجدولة التقويم 
الزمني للمشروع ورسم نهج للطرق المنوي استخدامها والقضايا ذات 
العلاقة بالمشروع. 
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أثناء المرحلة التالية» مرحلة التطوير»ء يبدأ إعداد التصميم 
التفصيلي ووضع النماذج البدائية للنظام؛ كما سيتم تفصيل متطلبات 
النظام» ووضع الخطط التفصيلية للمشروع. وأحيرا: في مرحلة 
التنفيذ» قد يستمر تفصيل المتطلبات». ولكن تطرأ بعض التغييرات» 
ما يتطلب دمجها وتكاملها مع المتطلبات الأساسية؛ كما تتم في هذه 
المرحلة بناء وتكامل واختبار النظام؛ وتستمر عملية التخطيط ومراقبة 
التطور ف في المشروع. 


خلال مراحل دورة حياة النظام جميعهاء يتم تنفيذ جميع 
الأنقطة المشروعة مسيفا “فين شن توبات “عديدة :من التفاصيل + 
وفي المرحلة التحضيرية تكون السمات الأساسية التي سيدعمها النظام 
هي الحاجة الأساسية للتخطيط وتقدير الفترة الزمنية والتصميم. وهذا 
ويتم تحديد مجال ومدة برمجة النظام في هذه المرحلة» كما يتم 
التطوير والتفصيل لدعم عملية نقل المتطلبات ومطابقتها في هيكلية 
النظام. 


بما إن التصميم يصبح أكثر تفصيلاً في مرحلة التطوير» يتم 
تحديد فترات سريعة ويتم توزيع المهام في هذه الفترات» لكت 
عمليات المتطلبات تفصيلية أكثر من ذي قبل. يجب أن يتم النقل 
المتقدم للمتطلبات في وحدات النظام على مستوى واجهة الاستخدام 
«(على الأقل للفترات السريعة الأولى)» وهذا يعنى أن المتطلبات 
عب أنه كر متميلة يوردقه الكناءة للفمام بقل المتطلرات إلى 
وحدات النظام. يجب تحديد تدفق البيانات قدر الإمكان. كما ينبغي 
تحديد المتطلبات المتخصصة (التي يتطلبها العميل لتلائم احتياجاته) 
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ومختلف أنواع التباين بين المتطلبات المتخصصة والمتطلبات 
الأساسية في هذه المرحلة. ويجب أن يتم تنسيق هذه الأنشطة مع 
خطط المشروع وأنشطة التصميم لضمان توفر التفاصيل حين 
احتياجها. وهذا يعنى أن هذه الأنشطة تستمر أثناء مرحلتى التطوير 
والبناء حتى يتسنى لمهندسي المتطلبات فهم المتطلبات التي تحتاج 
إلى تطوير تفصيلي أولاً. وهذا يتأتى من خطة المشروع ومصممي 
هيكلية النظام. وقد يحتاج مصممو هيكلية النظام المزيد من التفاصيل 
لاتخاذ قرارات التصميم المهمة. كما إن خطة المشروع ستحدد ترتيب 
إصدار الخصائص والميزات. ويجب أن يستخدم مهندسو المتطلبات 
ذلك لمساعدتهم على تخطيط أنشطتهم وترتيب أولوياتها. 


5-3 الملخص والاستنتاجات 

لقد وضحنا في هذا الفصل عملية هندسة المتطلبات الوظيفية 
للنظام وكيفية تعاملها مع الأمور المرتبطة بتطوير البرمجيات المورّعة 
المراكز. وعلى وجه الخصوصء. تُعتبر إدارة التغيير وضمان الجودة 
وتأثير هندسة المتطلبات في عمليات التصميم والتخطيط والاختبار 
كن الأموو ال تحسقق قدرا كبيرا هن الأعدية فى يله التويعة 
لجو عا وات الأمر استخدام عملية هندسة: المقطليات لأذارة :هذه 
الأنشطة بكفاءة. ويتم إنجاز ذلك في المنهجية التي نتبعها من خلال 
نماذج لغة النمذجة الموحدة للمتطلبات وتتبع التصميم وخطط 
المشروع وعمليات الاختبار بوضوح. كما تسهل منهجيتنا طريقة 
التعامل مع التغييرات التي تطرأ على متطلبات النظام. عادة ما يحدث 
التغيير نتيجة الانطباعات والآراء التي نحصل عليها من التفاعل مع 
العملاء والمساهمين أثناء الفترات البرمجية التكرارية العديدة. وقد 
يكون استيعاب: التخيزات: سهلا في البيئة المتنظمة ‏ لكن تنسبق 
المتغيرات في سياق تطوير البرمجيات الموزرّعة المراكز يكون أكثر 
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صعوبة نظراً إلى تأثيره المحتمل على فرق العمل الموزّعة العديدة. إن 
الحفاط. غلى عملية المتابحة من اللخصاتطن 'المتقدمة إلى المتطليات 
الواقعية والتصاميم والاختبارات المرتبطة بها وخطط المشروع تساعد 
في إدارة التغيير في المتطلبات وتأثيرها في فرق العمل المورّعة. 


6-3 أسئلة للمناقشة 
1. ماهي مظاهر المشروع التي تتأثر بتغيّر المتطلبات خلاف 
هندسة المتطلبات؟ 
2 كيف تحدد أنشطة هندسة المتطلبات المشروحة في هذا الفصل 
القضايا التي تفرضها المتطلبات المتناسبة مع احتياجات مشروع 
تطوير البرمجيات المورّعة المراكز؟ 
3. ماهي العوائق التي تعترض تنفيذ مثل هذه العملية في شركة ما: 


المراجع 
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(النصل الرابه 


المتطلبات اللازمة لهيكلية النظام 


كان باولو يعاني التعب. فقد عاد من رحلة حول العالم لزيارة 
عدد من مواقع التطوير والبرمجة في محاولة منه لإعادة المشروع إلى 
مساره. فقد كانت عملية البرمجة تسير بصعوبة. وكانوا متأخرين عن 
الجدول الزمني للمشروع. وكانت البرمجة غير مستقرة. ولم يكن 
باولو يستسيغ ذلك كله. فقد كان النظام الذي كانوا يعملون على بنائه 
شبيهاً بالنظم الأخرى التي بنتها الشركة من قبل. وقد كانت عناصر 
النظام مجمّعة بطريقة مرنة وواضحة المعالم إلى حد ما. ولا شك أن 
هذا المشروع افتقد إلى العقل المفكر. فقد كان مقتنعاً أن المشكلة 
كانت في فرق البرمجة التي تعمل عن بُعد؛ فقد بدوا كأنهم لم 
يفهموه قط. 

في العديد من المشاريع» سواء كانت الموزرّعة أو المنتظمة. من 
المهم فهم وإدراك المتطلبات بصورة كافية وهذا أمر مهم. إذ ترتبط 
المتطلبات بهيكلية النظام في مراحله المبكرة بحيث تنعكس على 
قرارات التصميم الأساسية. أما إذا لم يتم إدراكها وفهمهاء فقد 
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لا يتمكن النظام من اكتساب الخصائص والميزات المهمة إذ إنها 
ترتبط بالأداء وقابلية القياس وغير ذلك من مزايا النظم. هذا ولا 
تُكتشف المشاكل فى هذه الجوانب عادة حتى مراحل متأخرة من 
ذؤزة عناة السام عنوقد هون سمي المج حكن في بالاشارنم 
المنتظمة. وبالنسبة إلى مشاريع تطوير البرمجيات الموزعة المراكزء 
قد تقود هذه القضايا إلى توقف المشروع بسهولة. ويتضمن التعامل 
مع هذه الشؤول تتسيقا كيثر ا بد بين الفرق المسؤولة عن العديد من 
جوانب النظامء وهذا أدب ممه ل ف ا د تطوير 
البرمجيات المورّعة المراكز. وبفضل أحد عوامل النجاح الحاسمة 
«الحد الأقصى من الاستقرار» تعلمنا عبر الطريق الصعب أنه من 
المهم جداً جعل هذه المخاوف واضحة بطريقة تمكن من أخذها 
بعين الاعتبار في هيكلية النظام. 


نناقش فى هذا الفصل منهجيتنا فى تحديد المتطلبات المحددة 
ونقلها إلى ارق عرق طبه رسكل عاد إضافة إلى مناقشة الأمور 
المرتبطة بمشاريع تطوير البرمجيات الموسعة. ثم نناقش في هذا 
الفصل الأنشطة التى تتضمنها عملية جذب ونقل المتطلبات المنظمة 
لكي : 

بعد قراءة الفصل السابق» قد يبدو عدم تخصيصنا فصلاً آخر 
لهندسة المتطلبات أمراً غريباً. فقد وجدنا أن هناك تصنيفين للمتطلبات 
التي يستخدمها مختلف المشاركون لأغراض مختلفة. وتستخدم 
المتطلبات الموضحة في الفصل الثالث لتصميم وظائف النظام. فهي 
لا تحدد التركيبة الضخمة للنظام. وبتنحية تقنيات تصميم الكوائن 
الموجهةء يمكن أن تقدم العديد من بُنى النظام المختلفة الوظائف 
المطلوبة. عملياًء يكون الحال غالباً أن يتم برمجة هيكلية النظام 
بالتوازي مع برمجة المتطلبات. ما الذي يستخدمه مصممو هيكلية 
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النظام لمساعدتهم في اتخاذ القرارات؟ وكيف يعرفون الخيارات 
مجموعة من الناقلات الهيكلية المرتبطة (أو متطلبات الهيكلية المهمة) 
لتحفيز تصميم الهيكل الإجمالي للنظام. 


1-4 تمهيد 

يجب أن يدعم شيءٌ ما هيكلية النظام (أو الهيكل الإجمالي 
الوظيفية؟ خسنا .نعو لكن إذا دعمت" العديد من 'الهيكليات 
المختلفة الوظائف بالتساوي تكون أفضل هيكلية يمكن استخدامها 
هى الأرخصء أليس كذلك؟ ليس بالضرورة» فإن ذلك يعتمد على 
السياق. وفي بعض الحالات» يكون الحصول على أسبقيّة التسويق 
أمراً أكثر أهمية من الجودة والوظائف وإمكانية الصيانة. وفى حالات 
أخرى» قد تُستخدم الهيكلية لدعم خط الإنتاج وتكون تكلفة تنفيذ 
بمعنى آخرء يجب أن تدعم الهيكلية أهداف العمل الذي تقوم به 
الشركة. ونشرح في هذا القسم من الكتاب كيفية ترجمة أهداف العمل 
في هيكلية النظام بمزيد من التفصيل والمعلومات التي يتطلبها 
المورّعة المراكز فى هذه المعادلة. 

1-1-4 كيف ترتبط هيكلية النظام بأهداف العمل؟ 

فا هي العوافل التى :تؤثر عملياً فى قزارات التصميب ب التسية إلى 
كل شخص ذي علاقة بتصميم النظام؟ كم مرة تفكر بكيفية تأثير 
القرارات التقنية المهمة فى قدرة الشركة على تحقيق أهدافها؟ فى 
العديد من المشاريع» من المحتمل أنك لا تناقش مثل هذه الأمور. 
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وعملياء يتم العديد من النقاشات حول التصميم من دون وجود 
مجموعة واضحة من المعايير المتَّبعَة فى اتخاذ القرارات» مثل «هل 
نستخدم طريقة امال تعن على الأحدالة أم على الرسائل؟» أو 
«هل نستخدم لغة البرمجة 28/819 أو «1281)؟ تتأثر هذه المناظرات 
غالباً بالتفضيلات والآراء الشخصية والعوامل الأخرى التى يصعب 
تجافنيا' كيني عمد تاها عابر الكيهل: كذاه ولف قر نه 
الخيارات في خطوط الإنتاج في الشركة. نحن على علم بحالة واحدة 
على الأقل حدثت في شركتنا حيث نتج من اختيارات هيكلية 
البرمجية المهمة خسارة حصتنا فى السوق. وفى نهاية المطاف» قمنا 
ببيع عدد كبير من وحدات 00-6 ا 
مثال على ذلك : 


تحقق الشركة «4) جميع منتجاتها من خلال بيع أجهزتها 
ومعداتها. وتنتج الشركة تطبيقاً برمجياً يعمل على إدارة الشبكات لنظم 
المعدات. ولكن يوجد في الوقت الحالى خسارة (أي إن التطبيق 
عدد كبير من وحدات العمل. يدرك المديرون التنفيذيون فى الشركة 
أن المعدات أصبحت سلعةء ويتوقعون أن هوامش مبيعات المعدات 
ستضعف خلال العشر سنوات القادمة. ولضمان استمرارية أعمالهم 
لأطول فترة ممكنة» قرروا بناء نظام إداري جديد يمكن تحويله إلى 
أرباح. وقد تمّت طريقتهم في تصور كيفية تحول هذه البرمجية إلى 
عمل مربح بما يلي: 

1: التحد مد تكاليف. البرميجة“الداحلية. 

2 توسيع نطاق السوق. 

تخطط الشركة ههه للحد من تكاليف: البرمجة الداخلية عن 
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طريق استبدال التطبيقات الموجودة حالياً بتطبيق جديد. وترغب 
الشركة في توسيع نطاق السوق عن طريق الدخول إلى أسواق 
جغرافية جديدة وعن طريق فتح قنوات للمبيعات على شكل «موزعين 
ذوي قيمة مضافة 25هااء5ه 2780106-20060. ويقوم هؤلاء الموزعون 
ببيع البرمجية باستخدام علاماتهم التجارية الخاصة لدعم نظم 
المعدات الخاصة إلى العديد من مختلف المصئعين. 


وبالنظر إلى المثال السابق» يمكننا أن نرى العديد من الجوانب 
التي يبدو فيها تأثير أهداف الشركة في هيكلية النظام تأثيراً واقعياً 
وأساسياً من دون التأثير فى وظائفه. يجب اتخاذ بعض الاعتبارات 
لدعم عخطوط إنداح معدت التحدات: واقة موه قن بدت 
الأسواق اعتبارات تنظيمية» وتؤثر فيها الثقافة السائدة في المنطقة 
(على سبيل المثال» في بعض المناطق» يكون العملاء مستعدين 
للدفع بسخاء مقابل الحصول على خدمات التقنيين المدربين لتركيب 
وصيانة المنتج» بينما لا يدفعون لهذه الخدمات في مناطق أخرى)» 
هذا بالإضافة إلى اعتبارات اللغة (على سبيل المثال» القراءة من 
الأعلى إلى الأسفل» أو ترجمة الرسائل التحذيرية). 


وبالكشف عن المزيد من التفاصيل» تتحدد لدينا عوامل مؤثرة 
أخرى. إلى أيّ حد يمكن لأحد الحلول البرمجية دعم جميع هذه 
الأهداف؟ وما هي المقايضات والمخاطر التى تنطوي عليها؟ وهل 
يكون العمل ناس جرد شاه المشاط. اليفايفات أم هل 
يتوجب عليهم إدخال تحسينات وغربلة الأهداف (على سبيل المثالء 
الحد من الآسواق المنوي دخولها أو تغيير الجدول الزمني)؟ هذه 
جميعها هي قرارات عمل لكتنها ستلرم تدخل'المختصين التقنيين: 
وغالبا ما يكون هناك فصل بين ما ترغب الشركة في تحقيقه وما 
يتكو ريك زفاح #وعليه باع بوثيرة#المحاطر ينات الجسر 
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الذي من شأنه التقليل من هذه الفجوة. تلاحظ هذه الحالة في 
مشاريع تطوير البرمجيات المورّعة المراكز. فمن الضروري جداً 
معالجة عدم التطابق المحتمل الموجود بين توقعات العمل وجدوى 
الحلول التقنية» نظراً إلى أن كل الأمور تكون أكثر تعقيداً وصعوبةً 
بورمشاريم تطوكر اللرمهاك المراعة المزاكن 


2-1-4 ما هي العوامل المؤثرة في هيكلية النظام؟ 

كما أوضحنا فى حالة باس (2003 ,21.1 66] 8855)» تميل العوامل 
لقي توار تفن سكلية النشو تالت" أن تون حتفن الشدره 4 فقلى 
سبيل المثال» الأداء والأمن وقابلية التعديل والموثوقية. ومن مثال 
أهداف العمل الموضح أعلاه» يمكننا أن نرى بعض المخاوف 
المتعلقة بقابلية التعديل (مثلا» السماح للموزعين ذوي القيمة المضافة 
بإضافة العلامة التجارية الخاصة بهم إلى النظام) وتعديلات اللغة 
ومخاوف حول قابلية التكيّف (مثلاء القدرة على تهيئة النظام في خط 
إنتاج المعدات). وقد تنبثق مخاوف أخرى بسهولة كالآداء والموثوقية 
والتوفرء وهي أمور غير واضحة في المثال. في مشاريع تطوير 
البرمجيات المورّعة المراكز»ء هناك بعض العوامل الإضافية يجب 
أخذها بالحسبان غير تلك المتعلقة بخصائص الجودة. وسنناقش هذه 
الأمور بتوسع في قسم لاحق. 

غالباً ما ترى متطلبات تعرف ب «غير وظيفية». فقد وجدنا أن 
ذلك قد يؤدي إلى نقاش أو جدل جانبي بطريقة أو بأخرى. وغالباً ما 
تضهن المنظلبات المرقيظة بالميكلية كلا الترعين: وظيفية بوغير 
وظيفية. فبدلا من التركيز على إذا ما كان المتطلب «س» ذا طبيعة 
وظيفية أو غير وظيفية» نركز على إذا ما كان للمتطلب تأثير في 


البنية الإجمالية لهيكلية النظام. إن أحد المقاييس المعتمدة التي 
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يمكنك استخدامها لتحدد ذلك هو التساؤل عمًا إذا كان بمقدورك 
إنجاز المتطلب بكفاءة» بغض النظر عمًا إذا اتخذت القرارات بشأن 
الهيكلية الأولية ذلك بالحسبان. إذا كانت الإجابة «لا»2 فإنه ينبغي 
على مصمم الهيكلية النظر في ذلك المتطلب في المراحل المبكرة من 
عملية التصميم. 
3-1-4 ما هي المعلومات التي يحتاجها مصمم الهيكلية؟ 
لا يكفي القول (كما ورد في القسم السابق من هذا الكتاب) إن 
النظام يجب أن يكون قابلاً للتعديل والتكيّف ويسمح بتعديل اللغة» 
إذ إن أي نظام يكون قابلاً للتعديل من ناحية ماء كما يمكن أن يتم 
تعديل أي نظام في ما يتعلق بأي جانب بتوفر الوقت والمال الكافيين. 
والأسئلة التي تتبادر إلى الذهن هي: من أي ناحية يكون النظام قابلا 
للتعديل» ومتى يكون ذلك». وكم يلزم من الوقت لإجراء التعديل؟ 
وما هي الجوانب المحددة في النظام التي يجب تعديلها؟ وهل تحتاج 
إلى التعديل أثناء التشغيل» أم أثناء عملية ترجمة شيفرة البرمجة» أم 
أثناء التفويض أو أثناء البرمجة؟ وهل يستغرق إتمام هذا التعديل ساعة 
من الزمن» أم أسبوعي عمل» أم عشر سنوات؟ وتنطبق هذه الأسئلة 
على كافة الشؤون الأخرى. ويجب أن تكون التعديلات محددة بما 
يكفى لاختبارها فى ما يتعلق بالهيكلية. فعلى سبيل المثال» قد 
معطم : الشحصض المشوول كن المراسية اديه إذاءنا كانه الويكلية 
قادرة على إنجاز هذا المتطلب. يشرح باس (2003 ,[.81 اع] 82585) 
كيفية عمل ذلك بالتفصيل. ومن الأمثلة الأخرى في هذا السياق ما 
يلي : 
© إذا فشل «المتحكم بالمحول» في الاستجابة أثناء الحمل الطبيعي» 
يستشعر النظام هذا الفشل ويتابع التواصل مع النظام خلال 
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© سيكون المبريجون قادرين على استبدال النظام القائم بذاته بآخر 
يعمل من خلال شبكة الإنترنت خلال شهري عمل. 

© ستتم برمجة النظام بمستوى الجحودة ج22 ما يوفر مجموعة من 
وظائف تبهيئة الجهاز المتصل (0100©) خلال اثني عشر شهرا 
تقويمياً باستخدام ما لا يزيد على 360 شخصا. 

© سيكون مهندس النظم قادراً على استيراد اللغات الغربية غير 
المدعومة مسبقاً إلى النظام أثناء التشغيل من دون تدني مستوى 
أداء النظام إلى ما دون مستوى متطلبات الحمل العادي أثناء 
فترة الكمون. 


4-1-4 ما هو تأثير تطوير البرمجيات الموزّعة المراكز في 
هيكلية النظام؟ ١‏ 
يختص هذا الكتاب بتطوير البرمجيات باستخدام فرق العمل 
المورّعة في عدة مواقع. لماذا إذاً استغرقنا نصف الفصل في مناقشة 
متطلبات هيكلية النظام بينما تطرقنا إلى تطوير البرمجيات الموزعة 
المراكز بشكل أقل؟ هناك عدة أسباب تجعلنا نعتقد أن هذه المواضيع 
مرتبطة بمشاريع تطوير البرمجيات الموزّعة المراكز على عدة مواقع. 
أولآء لا يُصرح الناس غالباً بالمتحكمات التي تقود هيكلية 
البرمجيات. ففي حين يكون ذلك مقبولاً عندما لا يختلف النظام قيد 
البرمجة عن آخر نظام تم تطويره بحيث يمتلك الأشخاص المعنيون 
الخبرة في مجال العمل» غير أنه قد يؤدي إلى تأخير المشروع 
(601085». وتسببت هذه الاستكشافات غير المرغوب بها في تفكك 
العديد من المشاريع الموزّعة في عدة مواقع؛ إذ إنها تتطلب إعادة 
بعض العمل غير المخطط له مسبقاً. وقد يطال ذلك العديد من 
جوانب النظام. ولن تتمكن فرق العمل من التنسيق بشكل كافٍ 
لتعديل الوضع في الوقت الملائم نظراً إلى طبيعة المشروع الموزّعة. 
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قاتناء ست الى كانت#هدة أموو يدرلكة الاكتفافين المعفون كيف 
التعامل معها حدسياًء غير أنهم يجب أن يكونوا قادرين على جعل 
سياق ذلك الحدس صريحاً وواضحاً للفرق التي تعمل عن بُعد. ولا 
يمتلك أعضاء فرق العمل التى تعمل عن يُعد نفس الخبرة والبديهة» 
مكهزن كنك إلى الكديد من الجيتاعدة لقي الدوائم و الاين 
المنطقية لاتخاذ قرارات معينة. 

غالباً ما يقال إن عملية تطوير البرمجيات المورّعة المراكز على 
عدة مواقع تتطلب هيكلية ذات مكوّنات «معرّفة جيداً ومجمّعة بطريقة 
غير محكمة». وفى مثل هذه الحالةء لا تكون هذه المعرفة كافية 
لدان سني كاه يكو كه يمنا نكن الليييى أن كرت 
خيارات المصممين مبنية على مهارات الأشخاص الذين يضطلعون 
بعمل في المشروع. هذا ويجب اتخاذ اعتبارات مشابهة في الحسبان 
في مشاريع تطوير البرمجيات الموزّعة المراكز على عدة مواقع. غالباً 
ما يكون هذا الأمر معقداً. إذ قد يحضر بعض أعضاء فريق البرمجة 
من خارج الشركة» ما يعني جهلهم في مجال العمل. كما إنه من 
الشائع أن تكون المعرفة في مجال العمل المطلوب محصورة في 
قسم أو موقع معيّن. ويجب وضع وحدات العمل في الاعتبار منذ 
بداية تصميم النظام. كما يجب تحديد فرق العمل اللازمة لوحدات 
العمل إذا كان ذلك متاحاً بحيث يمكن المواءمة بين الفريق والعمل 
الذي يجب إنجازه. إضافة إلى ما تقدم» تقترن وحدات العمل مع 
النظام بمستويات وطرق مختلفة. وبشكل عام» يتضمن الاقتران الأكثر 
إحكاما وتعقيدا المزيد من التنسيق بين الفرق. إذا كنت تخطط لتوزيع 
العمل على فرقٍ غير قادرة على التنسيق والتواصل مع المجموعات 
المطلوبة» فلا بد أن يكون الوضع لديك غير ملائم. 

تؤدي هذه الاعتبارات إلى تحليل يختلف عما قام المصممون 
بتصميمه. إضافة إلى ذلك. تكون الارتباطات بين المتطلبات مقيدة» 
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إذ يلزم تنفيذ بعضها مع متطلبات أخرى في الهيكلية. ويجب أخذ 
هذه المبادلات في الحسبان في ضوء أهداف المشروع. ولا تكون 
التغييرات التى تطرأ على الهيكلية الخيار الوحيد. فإذا كان هناك 
تعارفى للا ودر كا رابع عجذااي3* قوم السك فنيظ مطل الشركة 
بطرق تساعد على ضمان التطابق بين الخيارات التقنية وقدرات 
الشركة التطويرية (تم شرح ذلك في الفصل السادس من هذا الكتاب 
- إدارة المخاطر). 


نعتقد أن مشاكل باولو نشأت عن عدم العناية بهذه العوامل على 
للشركة وبالتنسيق بين الفرق التاسيسية لما عانى تلك الكوابيس 


2-4 متطلبات الهيكلية المهمة 


1-2-4 تحديد متطلبات النظام 

غالباً ما نستخدم تقنية معيّنة لتحديد متطلبات الهيكلية المهمة 
(851) بناءً على منهجية ورشة عمل خصائص الجودة التي يعقدها 
بمعهد هندسة البرمجيات أععة82:6 :2002 ,[.21 أه] ا 521 
(2000 ,[.21 غ6]. إن الهدف من هذا النشاط هو تأسيس مجموعة من 
أكثر متحكمات النظام أهمية مرنّبة حسب الأولويات على هيئة 
سيناريوهات خصائص الجودة, التي تتم مطابقتها مع أهداف العمل. 
ونقوم بعقد مراجعات دورية لتحديد المتطلبات حسبما يكون ذلك 
ضرورياً. 

لضمان ممارسة العوامل التنظيمية التأثير الملائم في الهيكلية» 
فيا بطري معيحية جلت هده المعلونات إلى المعطليات المتحددة 
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بالهيكلية (2002 باقتانته2 :2000 ,[.21 أهء] عأ تعصمة810). تهدف هذه 
المنهجية إلى فهم خصائص الشركة وتعريف المناطق والنطاقات 
المرتبطة بالمصممين وإيصال هذه الاعتبارات بطريقة تسمح 
للمصممين بالتعامل معها. هذاء وقد تم شرح هذه المنهجية في 
الفصل السادس من هذا الكتاب أيضا. 


قبل البدء بتنفيذ هذا النشاط. يجب توفر أهداف النظام التي 
غالباً ما تكون أهدافاً عامة. ويُفترض أن الجميع يعلمون سبب قيام 
الشركة بإعداد ذلك النظام. فإذا لم تتوفر خطة واقعية للأسواق 
المستهدفة واحتياجات هذه الأسواق والفروق بينها والاعتبارات 
الخاصة بكل منهاء فالوقت ما زال إذاً مبكراً لعقد ورشة العمل هذه. 
وإذا لم يقم أحدهم بتوضيح هذه البنود بشكل تفصيلي واضح» يكون 
ذلك مؤشرا على وجود خطة عمل غير كافية للمشروع. إضافة إلى 
ذلك» يجب ضمان الرعاية لهذه العملية؛ ونظراً إلى طبيعة أصحاب 
المصالح المتنوعة» ويستلزم الأمر وجود شخص ذي مستوى إداري 
متقدم لضمان مشاركة أصحاب المصالح. 


1-1-2-4 ورشة عمل حول متطلبات الهيكلية المهمة 


لقنن ونا مقطوور ووقةعدل للمتطلنات' المي مو الناسية 
الهيكلية بناءًَ على ورشة عمل حول سمات الجودة عقدها معهد 
هندسة البرمجيات و[لة اع] أععوط2ة8 :2002 ,[.له أع] متممصاعة8) 
(2000. وفي حين أن معظم الخطوات التي ستنفذ في ورشة العمل 
شبيهة بتلك التي نفذت في ورشة عمل سمات الجودة» قمنا بتصميم 
هذا النهج في بعض المجالات ليلائم أغراضنا بشكل أفضل. وفي ما 
يأتي عرض للخطوات الأساسية في ورشة عمل أهم المتطلبات من 
ناحية الهيكلية. 
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الخطوة 0: التحضير 

تنفذ هذه الخطوة قبل عقد ورشة العمل. والهدف منها هو 
ضمان تحقق شروط المتطلبات السابقة للنجاح. ومن خبراتنا السابقة 
(وَالى كان بعضها هؤلما)ة كما بصياغة هذه الخطرة لإتاصة القرصة 
لإلغاء أو تأجيل ورشة العمل إذا لم تتحقق المتطلبات السابقة 
بجلاء) : 

© ضمان المشاركة المناسبة لأصحاب المصلحة 


وهو غالباً الجانب الأكثر صعوبة فى هذه الطريقة. وقد تكون 
المجموعة المثالية من أصحاب المضالح كبيرة توعا ها وتشمل 
المبيعات والصيانة والجودة والخدمات والتواصل والتسويق وغير ذلك 
من المشاركين. ومن الضروري وجود راع أو كفيل من الإدارة العليا 
يتفهم أهداف ورشة العمل ويؤمن المال اللازم لها وذلك لضمان 
الحضور الملائم. ومن الضروري أن يوجد عدد من الحضور بالحد 
الأدنى : 
- شخص يستطيع تصوير الأهداف الإجمالية للعمل المرتبطة 
بالمشروع أو المنتتج (السبب وراء هذا المشروع). 
٠‏ جعلون فين السوات والسوق يكونون افافزون نان اذوه 
الأسواق الرئيسة ووصف احتياجاتهم وبيئاتهم (ما يتطلبونه 
لبيع المنتج بنجاح أو اعتبار المشروع ناجحا). 
-- مصممو الهيكلية. 
© سياق العمل معلوم 
قد يبدو ذلك تعبيراً غير ضروري؛ فقد قمنا بإضافة هذا التعبير 
صراحةً بعد المشاركة في أحد المشاريع أو أكثر حيث لم يكن الهدف 
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من بناء المنتج غير واضح. وقد وفرنا في البداية يتؤي عاليا من 
التوجيه لما كنا نبحث عنه في سياق عرض السياق. ولكن بعد 
الحصول على جميع أشكال العروض تمنا بتطوير قالب أكثر تفصيلاً 
مزوداً بأمثلة لمساعدة الأشخاص فى الحصول على المعلومات التى 
يطلبونها. 

© إجراء الترتيبات اللوجستية 

نظراً إلى صعوبة ضمان الأوقات الملائمة للحضور» نجد أنه 
من المحبط ضياع الوقت في البحث عن الأقلام الخاصة بالآلواح 


وجول لسع وح كود المطاك. لعف 14 لوقي ف 


الخطوة الأولى: عرض طريقة ورشة عمل متطلبات الهيكلية 
المهمة 


إن الهدف من هذه الخطوة هو ضمان أن يفهم جميع الحضور 
المنهج المتّبع وما الذي يتوقعونه في ورشة العمل هذه. وسيتم تزويد 
أصحاب المصلحة بمواد للقراءة المسبقة بحيث تصبح المنهجية 
مألوفة لهم» ولكننا وجدنا أنهم نادراً ما يقرأون أو يفهمون المنهجية 
من خلال مطالعة المواد المطبوعة التي نوفرها لهم. لذا نبدأ الاجتماع 
بشرح المنهجية واستقبال الاستفسارات وتوضيحها لهم. ونخصص 
ساعة ونصف لهذه الخطوة. 

الخطوة الثانية: تقديم سياق العمل 

نرغب في تكوين قائمة مختصرة بأهداف العمل المشتقة 
للمشروع على شكل نقاط في نهاية هذه الخطوة. ولعمل ذلك» 
نطلب من أصحاب المصالح تقديم ما يأتي: 
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© سياق العمل (مقدّمة عامة عن أهداف المشروع). 
© الأسواق الرئيسة (وثيقة الصلة) والتي تصف: 
ب العملاء المستهدفين 
- مدى أهمية هؤلاء العملاء (كأن يكونوا مصدراً رئيسياً 
للدخلء أو ألا يكونوا ذوي أهمية ربحية» ولكنهم 
يلزمون للحفاظ على السمعة» وغير ذلك). 
0 جوانب المشروع التي قد تجعل هؤلاء العملاء يشترون 
المنتتج. 
© اعتبارات أخرى (كالبرنامج الذي يهدف إلى تقليل الزمن 
5 بالمئة). 
من النادر أن تكون كافة المعلومات متوفرة بالدقة والتفاصيل 
المطلوبين. ولضمان توفر تفاصيل تسمح بالاستفادة الفاعلة من ورشة 
الخطوة الثالثة : تحديد المتحكمات الرئيسة 
الهدف من هذه الخطوة هو بدء ترجمة متطلبات العمل إلى 
متطلبات هيكلية واقعية. وهذه المتطلبات عامة بطبيعتها وتوفر سياقاً 
للخطؤة العالبة نن مخطوائك إنشاء السيتازيوهات؟.وكال. على للف 
اعتبار إحدى النقاط المذكورة أعلاه. 
إن بيع النظام الخاص بنا إلى الموزعين ذوي القيمة المضافة هو 
جزء من الاستراتيجية التي سنستخدمها لتوسيع السوق. ويجب أن 
يعدم الموزعون ذوو القيمة المضافة بالقدرة على إضافة واجهات 
الاستخدام وإنجاز التهيئة والإعدادات الخاصة بهم أو القدرة على بيع 
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ذات صلة صنعها مورّد آخر. 


بالنظر إلى ذلك» نستطيع أن نرى أن النظام يجب أن يكون 
قادراً على استيعاب واجهات الاستخدام والإعدادات المختلفة التي 
يتم إضافتهاء ما يتيح للموزعين بيع المنتج بعلاماتهم التجارية 
الخاصة. إضافة إلى ذلك» سيتطلب النظام القدرة على التكيّف مع 
بروتوكولات عديدة تستخدمها أجهزة مضمّنة أخرى بحيث يديرها 
النظام. هذه النقاط ليست واقعية وصلبة بما فيه الكفاية لاستخدامه 
كمتطلبات للهيكلية لكنها تعبيرات عامة عن الأمور التى يجب أن 
تكون الهيكلية قادرة على تحقيقها لدعم أهداف العوكن المتكنو قن 
عليها أعلاه. خلال هذه المرحلة من مراحل ورشة العمل» نقوم بسرد 
«المتحكمات الرئيسة» ونستخدمها لتحديد السيناريو. 


الخطوة الرابعة : سيناريوهات العصف الذهني”*» 


نودت انو خلده التطر عو هري السيد كم ان الرقيقة إلن 
واقع. ونقوم بذلك عن طريق الطلب من أصحاب المصلحة بتقديم 
سيناريوهات خصائص الجودة (1999 ,02162 مه اعاوط:»11) التى 
تمثل اعتبارات: معينة.. قام معهن عئدسة البرمجيات عمل رائم في 
تحديد ماهية سيناريو خصائص الجودة بدقة» كما قاموا فى المعهد 


تمنيك محمرعة مون التستارينهاتك العامة الاستعدانها كدليل: ولق 


(*#) العصف الذهنى (05]0:128نة:6) هو طريقة عملية لجلب عدة حلول لمشكلة 
معينة» بحيث يجتمع مجموعة من الأشخاص المعنيين لتحديد المشكلة ثم التفكير بحلول لهذه 
المكلة بيت يم كان جيم الأفكار التي تعلق بالمشكلة في ورقة ثم حاولة اختيار المناسب 
منها لحل المشكلة. وعادة ما تُستخدم عملية العصف الذهني في الحالات الآتية: حل المشاكل 
وبناء فرق العمل والإعلانات التجارية والتخطيط العمل وإدارة المشاريع. 
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نقوم بإعادة سرد تلك المعلومات هناء غير أننا نقول إنه من المهم 
تحديد مقاييس مرتبطة لتحويل السيناريوهات إلى واقع. وبالنسبة إلى 
المتحكمات المذكورة أعلاه» قد يكون المقياس على شكل مستوى 
من الجهود اللازمة لإضافة واجهة استخدام جديدة أو مستوى الجهد 
اللازم لتطوير محوّل بروتوكول» وهذا من الأمور التي يصعب عملها. 
فالأشخاص غير معتادين على التفكير في احتياجات العميل في ما 
يتعلق بهذه الأمور. فمن المستحيل فهم الهيكلية التي يجب إنجازها من 
دون بعض القياس الكمي. أما ما نقوم به غالباً عندما لا يكون أصحاب 
المصلحة قادرين على تحديد وقياس احتياجاتهم فهو الطلب منهم 
عمل تخمين مدروس والإشارة إلى أن هذا القياس ليس مؤكداء ومن 
ثم الانتقال إلى المرحلة التالية. عملياً» يجب مراجعة هذه المقاييس 
عدة مرات أثناء عملية التصميم» وإنه لمن المساعد معرفة المقاييس 
المخمّنة من تلك المقاييس الثابتة تماماً. وفي هذه المرحلة لا نقوم بأي 
جهد لتصفية السيناريوهات أو جمعها أو تحديد أولوياتها أو رفضها. 
ويُعتبر هذا جلسة عصف ذهني» ونتعامل معه على هذا الأساس. أما 
التتتاريوقات المرئيطة .سيم تحديدها في خطوات»تالية: ولن يكوة 
ذلك جهدا مضنيا. سيكون هناك العديد من المتغيرات على هذه 
السيناريوهات والتي لن يتم تحقيقها هناء لكنك تحتاج إلى الحصول 
على مجموعة تمثّل تلك المتغيرات. وغالباً ما نطلب من كل من 
أصحاب المصلحة عرض سيناريو واحد على الأقل. 


الخطوة الخامسة : دمج السيناريوهات 


حالما نحصل على السيناريوهات الأولية نقوم بتنقيتها وهذا 
لدمج السيناريوهات. ونقوم باختيار السيناريوهات التي يجب توحيدها 
وجمعها معاً. ومن ثم العمل على تحديد السيناريو الذي يشتمل على 
جوهر المجموعة. إن أساس هذه العملية هو ضمان أن الشخص 
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الذي عرض هذا السيناريو هو الذي له الكلمة الأخيرة حول إذا ما 
كان السيناريو الناتج يوصل الفكرة التي كان يعنيها عندما قدّم 
العرض. وإذا لم يوافق ذلك الشخص على السيناريو» نقوم إما 
بتعديله إلى أن يحوز رضا ذلك الشخص أو نتركه خارج المجموعة. 

الخطوة السادسة: تحديد أولويات السيناريوهات 

ثمة طرق عديدة لتحديد أولويات السيناريوهات: يمكنك اتخاذ 
منهجية شاملة واستخدام بروتوكول تطبق فيه مجموعة المهتمين 
بالمشروع كاملة اقتراعاً على السيناريوهات التي يشعرون بأنها الأكثر 
أهمية؛ أو يمكنك الطلب من الأشخاص الذين يمثلون قطاعات 
العمل فقط تحديد أهمية السيناريوهات أو يمكنك استخدام طريقة 
أخرى لتحديد الأولويات. الأمر المهم هو أن تقوم بترتيبها على 
محورين وأن يكون لديك بروتوكول واضح ومنظم لترتيبها (وبخلاف 
حيث الأهمية بالنسبة إلى أهداف العمل (يجب أن يكون ذلك بعمل 
مطابقة سهلة» إذ إن السيناريوهات معدة فى سياق واحد أو أكثر من 
المتحكمات الرئيسة)» كما يجب ترتيبها حسب صعوبة إنجازها من 
وجهة النظر الهيكلية أو البرمجية. وهذا يقود إلى بعض الأمور المهمة 
للعمل والصعبة الإنجاز. هناك بعض المتحكمات (حوالى ثلاثة) التى 
ينتهي بها الأمر في تشكيل الهيكلية (قد يكون لهذه المتحكمات 
العديد من السيناريوهات التى تمثلها). 

الخطوة السابعة: الختام وإيجاز النتائج 

يتضمن النشاط الأخير تلخيص نتائج ورشة العمل بطريقة منظمة 
ومتماسكة وإخبار أصحاب المصلحة بما سيتم عمله بهذه النتائج 
وكيفية إكمال العملية. ومن الضروري تذكر أن هذه النتائج 3 
نهائية. وتضمن ورشة العمل بشكل أساسي أن الجميع لديهم نفس 
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لمفهوم للأهداف وتوجّه المشروع» وأنه تم تأسيس بنية معرّفة جيداً 
لمتطلبات الهيكلية وقناة اتصال ولغة مشتركة بين مصممى الهيكلية 
(أفضايا سونط فى نه لج علا مني أن سردن عي 
استمرارية تصفية ودمج المتطلبات (غالباً ما نعقد اجتماعات للمراجعة 
من أصحاب المصلحة بصورة منتظمة مجدولة). 


فكرة مفيدة: 

لا تقم بتحديد أكثر من خمسة متحكمات هيكلية. عملياًء 
من الشائع وجود العديد من المتطلبات (حتى أهم 
المتطلبات من ناحية الهيكلية)» لكن يوجد غالبا القليل 
من الأمور التي تحكم الهيكلية حقاً. فعلياً هناك متحكمان 
إثنان أو ثلاثة من هذه المتحكمات. بينما يكون هناك 
العديد من المتطلبات التى تعوّض المتحكماتء فإنها 
واف عق ين اناغ + أماد دواد الامو كل للف 
بكثير تصبح الهيكلية معقدة جداً. إذا وجدت أن لديك 
العديد من الشواغل» جرب أن تجمعها في مواضيع 
مرتبطة متقاربة من بعضها بعضا. فإذا ما زال لديك العديد 
من الشواغل» تأكد من ترتيب أولوياتها بوضوح بطريقة 
تجعل أمر تحديد أي منها يلزم جعل الهيكلية الأمثل 


2-1-2-4 المشاركون 


تتضمن الوظائف التي تم تحديدها للمشاركة فى ورشة عمل 
متطلبات الهيكلية المهمة ما يأتي : 


لا + قاقد ووشة العمل © بكون هذ السغص مسولا عم قنادة 


وتيسير أمور ورشة العمل ؛ ويجب أن يكون لديه : 
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- معرفة شاملة وكاملة بالأهداف وخطوات المنهجية. 

- معرفة بهيكلية البرمجية. 

*.مقازات التيسين والشييل وههارات شخصية عنازة (غالبا ما 
م يتفاعلوا بهذه الطريقة من قبل وهناك احتمال للاختلاف 
والجدال؛ ويتطلب الأمر براعة ومهارة للحفاظ على استمرارية 
ورشة العمل وأدائها بفعالية). 

ا كاتب ورشة العمل: هذا الشخص مسؤول عن تسجيل 
خرحات الاعسباعات بظابقة وشسة. من اللحكمة: الطلت 
من أعضاء آخرين مشاركين في ورشة العمل تسجيل 
النقاط المهمة والاحتفاظ بنسخ احتياطية. ذلك ليس مجرد 
دور إداري سلبي؛ فمن الضروري أن يكون هذا الشخص 
قادراً على: 

: فهم الطريقة والأهداف بحيث يمكنه تسجيل النقاط المناسبة 
بوضوح وذلك للحصول على المعلومات بالصورة المرغوب بها. 

- أن يكون واثقاً بما يكفي لضبط وتيرة هذا اللقاء لضمان 
تسجيل النقاط المهمة وتوكيدها من قبل أصحاب المصلحة. 

فريق ورشة العمل: يساعد أعضاء الفريق في الاستفسار 
وتركيز الاجتماع. ويجب أن يكونوا على دراية بمنهجية 
متطلبات الهيكلية المهمة ومعرفة بالهيكلية» ٠‏ وهذا أفضل دور 
يمكن أن يقوم به شخص جديد في هذا المجال. 
أصحاب المصلحة: وهؤلاء يوفرون محتوى المخرجات. 
يوضح الجدول 1-4 أصحاب المصلحة الذين يجب أن يشاركوا 
في ورشة العمل. 


كرون يرحات' هذه الععالة سيوع يزه الستسكمات اليكل 
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مرتبة الأولويات والتي يتم نقلها إلى أهداف العمل. وغالباً ما يكون 
الأمر وجود القليل من المتحكمات «الحقيقية» للهيكلية نسبياً. فإذا 
كان لديك أكثر من خمسة إلى سبعة متحكمات متقدمة المستوى» 
سيكون لديك الكثير لإدارته. وفى هذه المرحلة يمكن تصفية 
المتطلبات لتبقي منها ما هو مهمء ولكن يجب أن تكون هذه 
المتطلبات قابلة للتجميع ضمن شواغل رئيسة قليلة نسبياً. 
إضافة إلى الأمور الفنية المذكورة أعلاه (وربما أكثر أهمية 
منها)ء عليك في هذا الوقت أن تجمع مجموعة من أصحاب 
بناء النظام. وغالباً ما تكون ورشة العمل هذه المرة الأولى التي 
يحضر فيها أصحاب المصلحة مثل هذا الاجتماع (في بعض 
الحالات» قد تكون تلك المرة الأولى التي يجتمعون فيها)» ومن 
النادر أن يكون لديهم مفهوم مشترك للهدف من المشروع بشكل 
كامل. يجب أن يتم تسجيل هذا السياق والفهم المشترك وتركيبه في 
المشروع. قمنا بتفصيل ذلك في الفصل السابع. 
الجدول 1-4 أصحاب المصلحة المشاركون في ورشة عمل أهم المتطلبات 
من ناحية الهيكلية 
الوظيفة المسؤوليات 
مهندس المتطلبات يجب أن يكون مهندسو المتطلبات على معرفة 
بخصائص النظام الإلزامية. هذاء وغالباً ما يكون 
هناك علاقة مباشرة بين الخصائص والقضايا 
المتعلقة بالهيكلية. 
في المنتج لضمان تسويقه بنجاح. 
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راعي المشروع 


مصمم الهيكلية 


يقوم راعي المشروع بتمويل عمليات برمجة 
وتطوير المنتج. 

يقوم المصممون بتعريف هيكلية النظام ووصفها 
وتوضيحها؛ واتخاذ القرارات الفنية وتنفيذ نموذج 
مطابقٍ للهيكلية. وهم مسؤولون عن إكمال 
مجموعة المكونات بنجاح وتطوير اختبارات 
المواصفات واختبارات القبول لمكوّنات المنتج. 
يعمل مدير المشروع على إعداد خطة بدورة حياة 
المنتج كاملة وإدارة المتطلبات وفرق العمل لكل 
مشروع وتفويض فرق العمل لبرمجة وتطوير 
مكوّنات المنتج في مختلف أنحاء العالم. 

يوضح وكلاء العميل احتياجات مستخدمي المنتج 
النهائية . 


2-2-4 متابعة أنشطة المتطلبات 

تُعتبر ورشة العمل بحد ذاتها بمثابة الضوء الأخضر للبدء 
بفعاليات متطلبات الهيكلية المهمة وليست نهايتها. غالباً ما نتابع هذه 
الأنشطة بإجراء المزيد من التحليل التفصيلي (في مجالات يتم 
تحديدها خلال ورشة العمل) التي قد تتضمن إجراء المزيد من 
الفطليوات للندوف والمويف عد قنية القينا ريو قات سيد الخالات 
الخاصة والسيناريوهات ذات العلاقة والتوثيق ومتطلبات الهيكلية 
المهمة المورّعة على نطاق واسع. من المهم أن نأخذ في الاعتبار أن 
هذا النهج تكراري جداً ويرتبط بأنشطة دورة حياة المشروع الباقية. 
ونحن نوصى بشدة بعقد ورشة العمل الأولية مبكرا من دورة الحياة» 
بيد "أننا تعفد ووكنات عمل متابعة قصيرة الأمد (منظم بطريقة مختلفة 
بعض الشيء) بناءة على فترات زمنية مُجِدُوَلة ودورية لضمان أن يكون 


117 


الجميع متفقين خلال المشروع. تنخفض وتيرة هذه الاجتماعات 
بمرور الوقت» إذ تصبح المتطلبات والهيكلية أكثر استقراراً وتوازناً. 


3-2-4 التوثيق 

لا يعتبر التوثيق والإدارة أمرين بتلك الأهمية نظراً إلى أن عدد 
المتطلبات المهمة المرتبطة بالهيكلية قليل جداً (حتى بالنسبة إلى 
النظم الضخمة المعقدة) نسبة إلى المتطلبات الوظيفية. لكننا نطلب أن 
تكون هذه المتطلبات محددة في وثيقة عرض الهيكلية مع توضيحات 
لكيفية عنونتها والبدائل التي تم اعتبارها. ويكون ذلك مفيداً حين 
عرض وثيقة وصف الهيكلية لإحراز فهم سريع لأهم القضايا التي تم 
عنونتها. وينبغي أيضاً أن يكون هذا هو الحال في الأقسام الفرعية في 
وثيقة وصف الهيكلية. وتطفو هذه المتطلبات على السطح (بمزيد من 
التفصيل في بعض الأحيان) عندما يكون ذلك مناسباً. وقد تم شرح 
عملية توثيق الهيكلية بمزيد من التفصيل في الفصل الخامس من هذا 
الكتاب . 


3-4 الملخص والاستنتاجات 

ناقشنا في هذا الفصل منهجيتنا المتبعة لاشتقاق المتطلبات 
المهمة للهيكلية من أهداف المشروع. كما ناقشنا كيف يؤر توزيع 
العمل البرمجي في عملية التصميم. ولسوء الحظء ما زال هناك 
الكثير من المهارة والفن فى هذه العمليات. بينما قمنا بخطوات 
رامع في فل :تضاف المت السطمة لحكل الاق نينا قال 
هناك اتكال كبير على الخبرة (على الخبرة غير المنتشرة) وذلك لتنفيذ 
البرامج بدقة. وقد وجدنا أن العملية التي عرّفناها وانّبعناها تساعد في 
تركيز الاهتمام في المجالات الملائمة في الأوقات الملائمة» وذلك 
لتجنب بعض المزالق التي سببت فشل العديد من المشاريع السابقة» 
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وتؤدي هذه العملية في نهاية الآمر إلى جودة المنتج - والجودة العالية 
هي مفتاح السرعة العالية. 


4-4 أسئلة للمناقشة 
1. ناقش أهمية متطلبات الهيكلية المهمة بالنسبة إلى مشاريع تطوير 
البرمجيات الموزرّعة المراكز. 
2. ما هي التقنيات المتبعة لتحديد متطلبات الهيكلية المهمة غير تلك 
التي ذكرت في هذا الفصل؟ 
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الفصل الفاس 


تقوم شركة 480 بتطوير الجيل التالي من نظامها الذي يتضمن 
بوذا غلى الكوارف ويعفن سطلبات"الرين اللسقة © الميمة ققد 
كانت الهيكلية عبارة عن تحويل على نظام شركة ©48 السابق. وقد 
كان من المفترض نشر النظام في بيئة عمل تصل سعة الذاكرة فيها 
إلى 64 ميغا بايت (وهي أكبر مما كان عليه في النظام السابق). كما 
يوجد متطلبات الزمن الحقيقى دقيقة وصارمة لبدء التشغيل. وقد 
وجدوا في شركة 480 هذه المرة أنهم يستنفذون الحد الأقصى من 
الذاكزة للاستعداد. وقد تغير الهيكل التنظيمى لإدارة البرمجة عبر 
السنوات وهم يقومون الآن بتنفيذ نماذج مختلفة من النظام في خمسة 
مواقع في أوروبا. وقد سبّب ذلك العديد من التفاعلات بين فرق 
البرمجة المختلفة جيئة وذهاباً» وهذا بدوره تطلب تنسيق كافة 


(0*) نظم الزمن الحقيقي هي تلك النظم التي يتم فيها الاستجابة للأوامر والتغيبر 


مباشرة من دون إبطاء أو تأخير. 
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التفاعلات بين المكوّنات أثناء الاستعداد. كانت النتيجة النهائية لذلك 
أن البرمجة استغرقت ضعف الوقت المستحق وتجاوزت الميزانية 
الأصلية بنحو 80 بالمئة» ومع ذلك لم تحقق المتطلبات المستترة أو 
قفيود الذاكرة اللازمة للاستعداد. 

في المشاريع المنتظمة» تكون الهيكلية غالباً الأداة المركزية التي 
عن مشاريع تطوير البرمجيات الموزّعة المراكز. هناك عدد من 
الاهتمامات الخاصة حين إعداد هيكلية البرمجيات الموزرّعة. وحين 
النظر في عوامل النجاح الحاسمة» سيبدو جلياً أن الهيكلية في محور 
العديد منها. من الواضح أن الهيكلية أمر إلزامي لفهم الطبيعة 
المترابطة للمهام. كما يعتمد الحد الذي يمكنك تقليل الغموض 
وزيادة الاستقرار إلى أقصاه على كيفية عقد وتوثيق الأنشطة المهيكلة. 
ذلك هو الحال أيضاًء إذ إن التصميم الأمثل للمتطلبات لا يكون هو 
الأمثل بالنسبة إلى الشركة التي ينبغي عليها برمجة وتطوير هذه 
المتطلبات. ثمة مشاكل تعترض فرق العمل النائية لتطوير مفهوم 
مشترك بخصوص الهيكلية» وهناك حاجة إلى التنسيق الذي تفرضه 
الهيكلية والذي قد يكون تحقيقه صعباًء كما يصبح تطوير الهيكلية 
بكفاءة أمرأ صعباً بعد اكتساب المزيد من المعرفة. إضافة إلى ما 
تقدم» تعتمد القدرة على تنفيذ عمليات التخطيط والتقويم بكفاءة على 
الحصول على مدخلات معينة من أنشطة الهيكلية. ونركز في هذا 
الفصل على كيفية دعم عوامل النجاح الحاسمة وأخذ الشركة في 
الاعتبار أثناء تنفيذ أنشطة تصميم الهيكلية. 


1-5 تمهيد 
يُعرّف معهد هندسة البرمجيات هيكلية البرمجية على أنها (بنية 
أو بُنى النظام التي تتكون من عناصر البرمجية ومكوّناتها والخصائص 
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الخارجية الظاهرة لهذه العناصر والعلاقات التى تربط بينها» )ه] 8255) 
(2063 زه كه يكن الشكير :فى لبيك على أنها مجموعة من 
القرارات المففله مسينا تن دور عحياة التعميم التي شي يدؤرىا 
القرارات المستقبلية. وأما فى حالة تطوير البرمجيات المورّعة 
المراكز» فتّتخذ القرارات المسقاية بصورة أكبر بواسطة فرق البرمجة 
المورّعة في عدة مواقع. 

سنقوم في هذا الفصل بمناقشة كيفية تحديد القرارات المهمة 
التي يجب اتخاذها وكيفية فهم تأثير هذه القرارات وكيفية إبلاغ 
أعضاء الفريق بها. 

1-1-5 احتساب متطلبات سمات الجودة 

ناقشنا في الفصل الرابع من هذا الدليل تعريف «المتحكمات 
الهيكلية» للنظام» لكنه لم يشرح ماهيتها بصورة كافية. لقد ناقشنا 
عملية تعريف وتقويم متطلبات الهيكلية ذات الصلة في ما يتعلق 
بسياق الأعمال وذكرنا أنه يجب ألا يوجد أكثر من خمسة متحكمات 
هيكلية من دون ذكر التفاصيل. وقد يكون لديك من عشرين إلى 
خمسين متطلباً في نهاية ورشة العمل الخاصة بأهم المتطلبات من 
ناحية الهيكلية» حيث يتم تصنيفها حسب أهميتها بالنسبة إلى 
الأهداف التجارية» وقد يكون بعضها في غاية الأهمية بينما تكون 
أخرى غير مهمة. وعندما تحصل على التصنيف المطلوب» عليك أن 
تطلب من المصممين تصميم المتطلبات ذاتها بالنسبة إلى مدى 
صعوبة تحقيقها. ينتهى المطاف بالمتطلبات المهمة جداً للعمل التى 
يصعب تحقيقها لتكوث «المتحكمات الهيكلية» الحقيقية. 7 020 
أن الأمر ينتهي بها إلى ممارسة التأثير الأكبر في شكل الهيكلية. 57 
لا يعني أنك تستطيع تجاهل المتطلبات الأخرى - بل إنها لن تحظى 
ينفنين التاثير. في الفيكلية: 
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لا نقصد وصف عملية التصميم الهيكلي بتفصيل كبير هناء بل 
التوجيه والإرشاد إلى الجوانب التي تعتبر حرجة بالنسبة إلى مشاريع 
تطوير البرمجيات الموزرّعة المراكز بمزيد من التفصيل. وهناك قدر 
كمر مق المغرفة إلى هن ما بالالنات الييكلية العديد مق خصائضض 
الجودة المشتركة؛ الأمر المهم هو تحليل خياراتك لتحقيق متطلبات 
الهيكلية المهمة (وبالتالي تحقيق أهداف العمل). إن تسجيل الأسباب 
المنطقية للقرارات المهمة التى تُتخذ فكرة جيدة حيث يتسنى للآخرين 
الانتفاع من الأفكار 5 (ولا تنتهك هذه القرارات عن جهل). 
إن اختيار ترتيب المتحكمات والخيارات أمر متروك لك» ولكن 
عليك أن تأخذ في الاعتبار جميع المتحكمات والخيارات» كما ينبغي 
عليك إعادة النظر في القرارات السابقة» إذ إنه لا يمكن اتخاذ معظم 
هذه القرارات في معزل عن بعضها (نناقش المفاضلات بعد حين). 


2-1-5 احتساب الهيكل التنظيمي للشركة 


إذا توفر بعض الفهم للهيكلية المنوي إنجازها في الشركات 
النامية لدى مصممي الهيكلية» تكون لديهم فرصة لتصميم نظام قابل 
للتنفيذ. ويجب أن يعرف المصممون عدد فرق البرمجة التي ستعمل 
في المشروع والمسؤول عن إعداد هذه الفرق وميزات الأفراد» كنوع 
مجال المعرفة والخلفية التقنية التي يمتلكونها ومواقع وجودهمء 
والوحدات التنظيمية التى ينتمون إليها فى الشركة وإذا ما كانوا قد 
عملوا معأ مسبقاً. ومدى توفرهم للعمل حالياً. من هذه المعلومات» 
سيتوفر لدى المصممين فكرة عن عدد وحدات العمل لديهم ونوع 
الجهد المطلوب لكل وحدة عمل والمهارات التي يجب احتواؤها 
وغير ذلك. 


إذا نظرنا إلى المثال الموضح في بداية هذا الفصل» نجد أن 
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الحصول على تحليل للمطابقة بين الروابط والشركة يتطلب تنسيقاً 
معيناً. هذاء ويمكن اختيار بدائل أخرى كتخصيص ميزانيات لتوفير 
وحدات ذاكرة وجدولة الخوارزميات أو تقسيم النظام في ما يتعلق 
بالوقت والمساحة (ففي حين أن هذا يتطلب ضبط السعات التخزينية 
لكل قسمء فإنه يلقي الضوء بوضوح على القضايا حين نشوئهاء 
ويوضح تأثير هذه القضايا في تلبية إجمالي المتطلبات). ثمة بديل 
آخر يتمثل في تغيير الهيكل التنظيمي للشركة؛ على سبيل المثال» قم 
بتعيين مجموعة تُعنى بالجدولة واستهلاك موارد النظام» واطلب من 
تلك المجموعة إدارة التنسيق بطريقة منظمة. الآمر المهم هنا هو أنه 
لا يمكن إدارة المخاطر بطريقة فعّالة ما لم يتم تحديد هذه القضايا 
مبكراً (لمزيد من التفاصيل» انظر الفصل السادس من هذا الكتاب). 


3-1-5 إجراء مفاضلات الهيكلية 

كما أشرنا في القسم 1-1-5» تعتبر المفاضلات جزءاً متأصّلاً 
في عملية التصميم. ولا يمكنك تحقيق الاستفادة المثلى من الهيكلية 
فى ما يتعلق بالمتطلبات المرتبطة بها (مثلاً» إن تحقيق الأداء الأمثل 
ع التأثير فى قابلية التعديل)» لذا يجب إجراء حلول وسطية بحيث 
تشكل الأماس الش إرالك الأعمان: لمن ضيه أن الممنمين 
يكونون في مواقع اتخاذ القرارات (مع أنهم لا يتخذون هذه القرارات 
ضمنياً). فما لم يخبر المصممون الأشخاص المسؤولين عن وضع 
خطة المشروع عن أي قضية» وما لم يعرفوا تأثير هذه القضية في 
العمل»؛ فإنهم لن يكونوا في موقع يسمح لهم باتخاذ القرارات 
المثلى. وهذه هي فائدة تطوير متطلبات الهيكلية المهمة بالطريقة التي 
أوصينا بها في الفصل الرابع. وهي وسيلة للمصممين والأشخاص 
المعنيين بالأعمال للتواصل واتخاذ القرارات التقنية التى تؤثر فى 
خطوط الأعاع. في العكل: :لقا مسن المهم بإعطاء أصتعاب: المضلحسة 
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الملائمين فرصة فهم القضايا والخيارات لتوفير مدخلات للمشروع. 
ونوصى بعد اجتماعات دورية مجدولة لتحقيق ذلك. 


2-5 تصميم النظام 

يوضح الشكل 1-5 مخطط سير تصميم الهيكلية. كما ذُكر سابقاً» 
لا ننوي الدخول في التفاصيل لوصف كيفية تصميم النظام. وبدلاً من 
ذلك» نركز على جوانب عملية التصميم المرتبطة بتطوير البرمجيات 
المورّعة المراكز أو توفير مدخلات للعمليات الأخرى كعملية 
التخطيط. وبقراءة الفصول التالية» ضع في اعتبارك أن تلك ليست 
قائمة متسلسلة؛ ففى حين أننا قد وصفنا هذه الأنشطة بصورة مستقلة 
من أجل الوضوح. غير أنها مترابطة عملياً وتحدث بشكل متكرر. 


الشكل 1-5: مخطط عمل لتصميم الهيكلية 
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1-2-5 تحديد وحدات العمل 


في بعض المراحل» يجب تقسيم النظام إلى وحدات وظيفية 
يمكن تخصيصها إلى فرق العمل لبرمجتها وتطويرها. ولن نخوض 
في تفاصيل كيفية عمل ذلك (تعتبر هذه العملية في الكثير من الأحيان 
ااام نضا عن كرنيا قاط امن أنضطة هدي الزرسيات أ نكها 
سنركز على النقاط المهمة المرتبطة بتطوير البرمجيات الموزّعة 
المراكز أو التى لها تأثير فى فعاليات أخرى موضحة فى مكان آخر 
في هذا الكتاب. ْ ْ 

في كتب التصميم» تكون المصطلحات الخاصة التي يستخدمها 
المؤلفون مربكة؛ ففي بعض الحالات» يبدو الأمر كأن المؤلفين 
أنفسهم غير متأكدين من معاني هذه المصطلحات (في واقع الأمر 
وجدنا كوننا خمسة مؤلفين لهذا الكتاب بأننا غالبا ما استخدمنا 
تعبيرات غير متجانسة)؛ وهذا الأمر وارد جداً فى أبحاث ودراسات 
سكلة البرمجيانف وما رل ريات ستمو ندا مرو الاستهدام التفرط 
للمصطلحات. عندما نتحدث في هذا القسم عن تقسيم النظام إلى 
وحدات وظيفية» سنتكلم عن الوحدات الثابتة (نستخدم التعبير 
«وحدة» لتفيد ضمنيا معنى وحدة شيفرة البرمجة الثابتة». في حالاات 
كثيرة» سيكون هناك مطابقة معقولة بين عناصر وقت التشغيل 
والوحدات الثابتة أو الحزم (وقد يكون هذا هو سبب الإرباك)» لكنها 
لن تكون مطابقة مثالية. سيكون هناك وحدات ثابتة أكثر من وحدات 
وقت التشغيل» إذ قد لا تتوفر بعض الكوائن والوحدات كطبقات 
الأدوات البرمجية (01988565 '18(9[انا) كتوفر كوائن وقت التشغيل. 

هناك عدة أمور تحكم كيفية تحديد التقسيم الوظيفي للنظامء 
على سبيل المثال» الخبرة السابقة والمتطلبات المهمة للهيكلية» 
والموارد المتوفرة والأنماط ومعلومات الشركة. نظرياً» ستأخذ بعين 
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الاعتبار متطلبات الهيكلية المهمة ذات الصلة. أما عملياًء فتعتبر 
الخصائص التالية من الأمور التي تؤثر في عملية التحليل: قابلية 
الفيفيل وكايلية الفوسيمتوقابلية التفيو» رضافة إلى مدق الوقن ذا 
كان الأمر أنك تقوم ببرمجة خط الإنتاج» وأنك قمت بتعريف أوجه 
الشبه والمتغيرات» فإنك سترغب في التأكد من تضمين الأقسام 
المتغيرة في نظامك وذلك لإتاحة الفرصة لإنشاء المنتج المرغوب به 
بسهولة. إضافة إلى ما تقدم» إذا كان هناك احتياجات مختلفة لتوفر 
عدد متنوع من مزايا النظام فقد ترغب بعزل هذه المزايا (وهذا ينطبق 
أيضاً على أداء الزمن الحقيقي). ستحكم أنواع متطلبات الهيكلية 
المهمة عملية تقسيم النظام» لذا سترغب في التأكد من أن نظامك قد 
جزَّئ إلى وحدات تنفيذية. ويتضمن الفصل الثامن بعض الإرشادات 
والمبادئ التوجيهية عن تحديد السعة المثلى للوحدات» ولكن تقسيم 
النظام يحتاج بشكل أساسي إلى تسهيل عملية التقسيم. 

عندما نقوم بتعريف الوحدات القابلة للتنفيذ» يجب أن نأخذ في 
الاعتبار فرق العمل التي ستعمل على برمجة النظام. يجب ألا ينسى 
مصممو الهيكلية الفريق الذي سيقوم بعملية التقسيم وذلك لضمان 
وجود فريق عمل مناسب للوحدات التي يتم تحديدها (يتم عمل ذلك 
أثناء عملية المراجعة). إذا لم يتوفر فريق مناسب» يجب أن يحاول 
المصممون إيجاد بدائل. فإذا كانت البدائل أقل من الفريق المثالى 
الذي يطمحون له في ما يتعلق بمتطلبات الهيكلية المهمة الوق 
فنلكة الل وويطرية الام ارا مفاضلة بين البدائل التى قد تكون على 
قن مسلليات ينيحة له 14 كي وسينية أن بإفادة سيكلا عضن 
جوانب الشركة (سنناقش عملية إعادة هيكلة البدائل فى الفصل 
السادس ‏ المخاطر)»ء أو قد تتم المفاضلة بزيادة الميزانية 31 جدولة 
المشروع. نتيجة لتنفيذ هذه الفعالية سيتكون لديك تحديد للوحدات 
التي تُشكل النظام على الأقل» وبعض أنواع تقويم سعات الوحدات 
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ووصفاً لمسؤوليات كل وحدة من الوحدات. إذا تطلب الأمر اتخاذ 
قرارات حاسمة سيكون من الجيد توثيق هذه القرارات وما تحاول 
إنجازه (مرجع لمتطلب أو اثنين من المتطلبات) والبدائل التي تم 
بحثها والأساس المنطقي الذي سيُعتمد لاختيار البدائل. 


كلما تقدم المشروعء فسيتطور هذا العمل بتوفر تعريفات كاملة 
وثابتة للتقسيم الوظيفي ومخططات النشاط التي تحدد كيفية تحقق 
المزايا والخصائص في الوحدات ومواصفات واجهة التطبيق 
والعلاقات المترابطة. سنناقش عملية توثيق هذه الأهداف وغيرها فى 


القسم التالي. 


1-1-2-5 المشاركون 
يعرض الجدول 1-5 قائمة المشاركين الذي يقومون بتحديد 
وحدات العمل ومسؤولياتهم الأساسية: 


الجدول 1-5: المشاركون في نشاط تحديد وحدات العمل 


الوظيفة المسؤوليات 
ع الوك اصع سر لامي فرك الها يني كاي قو 
سيول عن الفسين الوظني: 


المثالية للوحدات بناءً على أنشطة التخطيط. كما 
يتوجب على مدير المشروع تقديرات السعات 
التخزينية لكل وحدة. كما يوفر المعلومات عن 
مواصفات فرق العمل. وهذا أمر مفيد لضمان توفر 
فرق عمل ذات مهارات وخبرات كافية لبرمجة 
وبرمجة الوحدات التي يعرفها مصممو الهيكلية. 
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مهندس المتطلبات يساعد مهندس المتطلبات في توضيح متطلبات 
العمل والمشاركين في مراجعة التصميم أو 
الأنشطة الأخرى لضمان أن المتطلبات معرّفة 
بشكل كافٍ. 


2-2-5 تحديد مسؤوليات الوحدة 


سيحتاج مصممو الهيكلية في وقت من الأوقات إلى تحديد 
أجزاء النظام التي تعمل مع بعضها بعضاء وذلك لتحقيق خصائص 
النظام المحددة في المتطلبات (انظر الفصل الثالث من هذا الكتاب). 
وهناك ثمة اقتران ضعيف بين هذا النشاط وتحديد وحدات العمل 
(التي تم وصفها في القسم السابق). قبل تنفيذ هذا النشاطء يجب 
توفر نموذج للمتطلبات وتعريف أولي لوحدات النظام. وهذا النشاط 
تكراري (كما هو الحال في معظم الأنشطة الأخرى) ما يعني أنه 
سيتم تنقيح نموذج المتطلبات والوحدة الثابتة في النظام بالتوازي مع 
هذا النظام. من الواضح أن المتطلبات المحددة التي يتم العمل فيها 
يجب أن تكون ثابتة بشكل منطقي قبل تنفيذ هذا النشاط. 


ستتطوّر هذه الوحدة الثابتة كنتيجة لتنفيذ هذا النشاط. وبالنظر 
إلى المسؤوليات بمزيد من التفصيل» ستثار تساؤلات حول إذا ما 
كانت المسؤوليات ستستمره وأن إجراء تعديلات على الأهداف 
الثابتة أمر لا مفر منه. 


ناقشنا في الفصل الثالث كيفية تنقيح الخصائص والمزايا التي 
حددتها مجموعة التسويق فى المتطلبات الواقعية. ويمكننا تحديد 
المتطلبات على مستوى النظام حالما تتوفر المتطلبات الواقعية 
التفصيلية (فكر بهذه المتطلبات على أنها الواجهات الخارجية للنظام). 
ثم نحتاج إلى إسناد المسؤوليات لمختلف الوحدات في النظام بحيث 
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تتحقق النتائج المرجوّة. لتعزيز رغبتنا في الإبقاء على عملية التتبع؛ 
قمنا باستخدام لغة النمذجة الموحدة (نقوم بإنشاء قسم للتصميم 
لنفس نموذج المتطلبات). كما نستخدم مخططات التفاعل (وهي 
مخططات التسلسل”*) لتوثيق المتابعات خلال النظام. نقوم بتحديد 
النظام. ستجد هذه المناهج طريقها في آخر الأمر إلى الجدول الزمني 
(الموضح في الفصل السابع ‏ التخطيط). يوضح الشكل 2-5 مثالاً 
لمخططات التسلسل. 


مخرجات هذا النشاط هى عبارة عن مجموعة من مخططات 
التسلسل :التي تصيفه كيفية تحقق. المتظلبات: في النظام. .هذاء 
وسيتطور نموذج التصميم كجزء من هذه العملية» وسيكون هناك 
العديد من المناهج التي تم تحديدها بالإضافة إلى أنواع البيانات 
النظرية المرتبطة التي يجب الاتفاق عليها. سيتطور الهدف الثابت 
أيضاًء كما ستنشأ القوانين التى تحدد مسؤوليات الوحدة. إذا كانت 
هذه القوانين مهمة (بمعنى وجود تأثير أو أكثر في أهم 
المتطلبات من ناحية الهيكلية)» يجب أن تكون واضحة صريحة 


وموتقه. 


1-2-2-5 المشاركون 
يقوم فريق الهيكلية بتنفيذ هذا النشاط. وغالباً ما يقوم أعضاء 


(*) المخطط التسلسلي في لغة النمذجة الموحدة هو نوع من المخططات التفاعلية التي 
توضح كيفية تفاعل العمليات التي تعمل مع بعضها بعضاً وبأي ترتيب. ويعرض هذا المخطط 
العمليات المختلفة على شكل خطوط عمودية متوازية والرسائل المتبادلة بين العمليات على 
شكل أسهم أفقية وفق ترتيب حدوثها. وهذا يوفر عرضاً لخصائص سيناريوهات الزمن 


الحقيقي بشكل رسم بياني. 
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فريق الهيكلية ببعض المشاركة أو المراجعة لضمان تحقيق المتطلبات 


١‏ ا 
١‏ 


أزلمميدعم ,مهرود إدصلها 
وت تتتت] 


مهعم |مما همود 1 


الشكل 2-5: مثال على مخطط توزيع متطلبات النظام 
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3-2-5 تحليل الروابط 


كما ذُكر سابقاً في هذا الفصل وفي فصول أخرى» من الصعب 
تسهيل التنسيق بين الفرق التي تعمل في عدة مواقع جغرافية. وتملي 
النقاشات التي نجريها أثناء تصميم النظام مقدار التنسيق اللازم خلال 
المشروع. من الواضح أن بعض الأمور كالتواصل الصريح والضمني 
بين الوحدات تنطوي على روابط» ولكن يمكن أن يكون لديك أنواع 


أخرى من الروابط الأقل وضوحا. 


نعرّف الترابط في إطار هذا السياق كمظهر من مظاهر الوحدة 
التي تعتمد على وحدة أخرى أو على مظهر من مظاهر النظام. وقد 
يكون ذلك ترابطاً تركيبياً كالاعتماد على طريقة محددة أو على تنظيم 
محدد للبيانات أو سلوك دلالي أو سلوك زمني أو سلوك خاص 
بالموارد. في مرحلة من المراحل» ستعتمد كل وحدة على غيرها من 
الوحدات تقريبا (مثلا إذا تشاركت جميع الوحدات في وحلدة المعالجة 
المركزية فسيكون لها روابط). الحل هو بتعريف الروابط التي ستتطلب 
تسيقا بين فرق العمل. وهذا أمر ضروري لتحديد جدوى قيام شركتك 
ببرمجة الحلول التي يتم تصميمها (سيناقش ذلك في الفصل السادس - 
المخاطر). ومن الطرق المفيدة والعملية في هذا السياق النظر إلى 
العلاقات:بيق التواصل الضمني والصريح (مفلاً شر الاشتزاك) 
والعلاقات بين الاستخدامات (مثلا تستخدم إحدى الوحدات الطبقات 
البرمجية من وحدة أخرى) وتطوير مصفوفة الترابط (انظر: الشكل 
3-5). وكخطوة ثانية» انظر إلى متطلبات زمن التشغيل الحرجة من 
قائمة متطلبات الهيكلية المهمة (مثلاً متطلبات الأداء أو التوفر)» ثم قم 
بتحديد أجزاء النظام التي تشترك في تحقيق هذه المتطلبات. وغالبا لا 
تتم هذه الطريقة في النظر إلى النظام لكنها توفر فهماً عميقاً يساعد في 
تجنُّب التكاليف الساذجة التي قد تتكلفها الشركة. 
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الوصول إلى البيانات 
تقويم الشروط 
تخيّر القيمة 
مدير المحول 
عرض الصفات 
معالجة الإنذار 
محرك قاعدة الإنذار 
تحرير وعرض 
التسلسل الهرمي 
عرض الإنذار 
محرك بحث قاعدة 
+121 
محرر القواعد 
تسجيل الدخول 
عدد التوابع 


اعم 


16 


12 


10 


13 


دم 


لقائمة التفسيرية للشكل 


6 


2 


1 


1 


1 2 2 3 1 2 10 1 


الشكل 3-5: مثال على مصفوفة الروابط 


1 


0 0 1 1 1 


1 بالخط العادي - روابط طبيعية 


نحصل من هذا النشاط على ما يسمّى عرضاً لروابط النظام. 
ويجري تنفيذ معظم هذا العمل أثناء مرحلة التطوير 6078802هاء) 
(356م لدعم التوجه نحو توزيع العمل على الفرق. إذا كان ذلك أكثر 
خطورة من منظور تطوير البرمجيات الموزّعة المراكز (انظر الفصل 
السادس من هذا الكتاب)» يجب إبداء المزيد من الاهتمام بالروابط 
في النظام بتطور التصميم. إذا كانت الروابط ناشئة في المناطق 
الحرجة من النظام التي تنطوي على درجة عالية من التنسيق» فإنه 
يجب تحديد ذلك مبكراً ما أمكن حتى تتخذ الخطوات المناسبة (انظر 
الفصل السادس من هذا الكتاب). فى هذه الحالات» يمكن اختيار 
آليات هيكلية بديلة. ْ 


1-3-2-5 المشاركون 
يعرض الجدول 2-5 المشاركين الذين ينفذون عملية تحليل 
الإرايط” الإضافة إلى سوؤر ابا كل مهن 


الجدول 2-5: المشاركون في نشاط تحليل الروابط 


الوظيفة المسؤوليات 

مصمم الهيكلية مسؤول عن تحديد الروابط 

مهندس المتطلبات يجب أن يكون موجوداً لتوضيح 
المتطليات 


4-2-5 تحديد المسارات الحرجة 


يجب تحديد بعض الاحتي لبرمجية في بعض المراحل 
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جنيك «المشاوات التمرعة'" فى ارسي يمسن أخره شين أ 
وحدة تتضمن روابط استخدام إلى أن المستخدم في تلك العلاقة 
يمتلك معرفة أساسية في «تمثيل الاستخدام». ولأن فرق البرمجة 
المتباعدة مسؤولة عن التصميم التفصيلي لمظاهر الوحدات الداخلية» 
يجب أن يتم تصميم (وحتى برمجة) وحدات «تمثيل الاستخدام» قبل 
تصميم وحدات «المستخدمين». ويمكن تحديد المسارات الحرجة 
بالنظر إلى النظام بهذه الطريقة. 


يتم تنفيذ هذا النشاط للتحضير لعملية التخطيط» ولذلك تبدأ 
متأخرة في مرحلة التطوير. يجب أن تكون المسؤوليات ثابتة (بالنسبة 
إلى الور الذي تتم برمجته على الأقل)» كما يجب الانتهاء من 
التخطيط المتقدم. يجب توضيح الخصائص التي سيتم تخصيصها في 
إصدارات مفردة والروابط بين هذه الخصائص. ينتج من هذا النشاط 
نوع من مصفوفات الروابط التي توضح الروابط البرمجية بين وحدات 
النظام. 


1-4-2-5 المشاركون 
ينفذ هذا النشاط أعضاء الفريق المختص بالهيكلية. 


فكرة مفيدة: 
أبتي حجم فريق الهيكلية صغيرا ما أمكن. وعلى الرغم 
من أن عدد الأدوار والمسؤوليات محدد» غير أنك يجب 


(95) (0هطاعص طنهم لوعناته - 0234). طريقة المسار الخرج (534©) أو تحليل المسار 
الحرج هي خوارزمية رياضية لجدولة مجموعة أنشطة المشروع. وهي أداة مهمة لإدارة المشاريع 
بفعالية. تساعد هذه الأداة في توضيح ترتيب تنفيذ الأنشطة والأنشطة التي يمكن تنفيذها في 
نفس الوقت وعدد الأفراد الذين يلزم توظيفهم لتنفيذ أنشطة المشروع. 
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أن تحد من حجم فرق الهيكلية» إذ تعمل الفرق الأصغر 
حجماً بصورة أسرع» وتساعد في الحد من الاستثمار 
المطبق في مرحلة التصميم المتقدم. يسبب تعيين عدد 
كبير من المصممين في فريق المشروع ما يمكن أن نطلق 
عليه وضع «كثرة الطباخين» الذي قد يؤدي إلى «شلل 
التحليل». أكثر الأدوار أهمية هي الأدوار التي يضطلع 
بها مدير المشروع والمصمم.ء إذ يلعبان دوراً مهمأ في 
تقدم المشروع بكفاءة أثناء مرحلة التطوير. غالبا ما يعمل 
الأشخاص الذين يلعبون أدواراً رئيسية في المشررع 
كمراقبي عمليات لأنهم الأكثر خبرة ولأنهم عملوا مسبقاً 
في مشاريع مشابهة. 


5-2-5 توثيق الهيكلية 

0 المذكورة أعلاه عروض خاصة 
للنظام قيد الإنتاج. ونذكر لاحقا بعض العروض الإضافية للنظام 
ونناقش صلتها الوثيقة من وجهة نظر مشاريع تطوير البرمجيات 
المورّعة المراكز. لن نناقش قضايا عامة ولا أهداف عملية توثيق 
هيكلية النظام» بل نوصي بالتوثيق كتابة. في كثير من الأحيان» توق 
الهيكلية كتابة من دون التفكير في القارئ» فغالبا ما نرى وثيقة 
ضخمة خاصة بالهيكلية تعطى لأي شخص يرغب في معلومات عن 
الهيكلية. ولا يكون القصد من وراء هذه الوثيقة القراءة من الغلاف 
إلى الغلاف كالروايات؛ بل يبحث القرّاء عن مواضيع معينة يقرأونهاء 
لذا يجب أن يركز المؤلفون على احتياجات القراء قبل الشروع في 
الكتابة وعرض بعض الإرشاد والتوجيه حول كيفية الوصول إلى 
المعلومات الملائمة. ولمزيد من المعلومات عن توثيق هيكلية 
البرمجيات» يرجى الاطلاع على (2002 ,21.1 اع] تامعصعاك) . 
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1-5-2-5 عروض التنفيذ 

تُصور عروض تنفيذ النظام كوائن زمن التشغيل والآليات التي 
تستعملها هذه الكوائن أثناء تفاعلها مع بعضها بعضاً. وهي تصور 
مكوّنات النظام كالعمليات والكوائن ومستودعات تخزين البيانات 
والروابط التي تمثل آليات التفاعل بين المكوّنات. وهذه المكوّنات 
والروابط هي العناصر الممثلة في نوع العرض. 


يفيد هذا النوع من العروض كلا من: 


عاد “الخمميع محال العم و التكرة والاتفطياطة والمكيولوها 
الذين يستطيعون بيان صفات الهيكلية ومتطلبات خصائص 
الجودة التي يجب أن يلتزم بها النظام. 
- أصحاب المصلحة (من خارج الشركة) كالعملاء ومقيّمي 
المشروع الذين يستطيعون فهم عناصر التنفيذ الرئيسة للنظام 
(بما في ذلك مصادر البيانات المشتركة المهمة) وتفاعلاتها - 
وهي بالتاللي تعمل كوسيلة للتحقق والمصادقة على خصائص 
المشروع. 
مسورل ييا البروع الدين بمسطيعون امير ان عل فظره 
عامة عن النظام كنقطة بداية لتعديله وتوسيعه مستقبلا. 
لهذا السيم تشتكدى عرن العدية ديه الرؤاط المهذة بن 
المكوّنات الموصوفة في وقت التشغيل. ويوفر التتبع بين عرض 
تخصيص العمل الثابت وعرض التنفيذ بصيرةً إضافية نحو روابط زمن 
التنفيذ التى نجدها بين وحدات العمل المخصص لفرق البرمجة 
العديدة. 


2-5-2-5 عروض التطبيق 
توضح عروض التطبيق أجزاء النظام الفريدة والمجموعات غير 
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المتداخلة من الوحدات التنفيذية القابلة للتقسيم هيكلياً. ومن الأمثلة 
على وحدات التطبيق : (0325326508665) فى لغة البرمجة «818:1). 
والحزم في للغة بعانا 1392 كم أعيدات عديدة لهذه العروض في 
النظامء منها: 


- تبِينٌ كيفية تحليل شيفرة البريجة المصدرية. 

- تبِينٌ العلاقات المختلفة بين الوحدات التنفيذية. 

- اعتبار الوحدات التنفيذية التي تحقق وظائف النظام كما تم 
تقسيمها في عروض التنفيذ» وبالتالي تحقيق متطلبات 
مواصفات ا لحودة. 
البرمجحة لوضع خطة الجدوى. 

يفيد هذا النوع من العروض كل من: 

: مدير المشروع الذي يجب أن يجدد مهام العمل التي تم 
فصلها عن بعضها بعضا بمنطقية تسهل تفويضها عبر فرق 
الترعة: العديدة المررعة :و المشتطيلة تغرى اعحضها يعها . 

- المختصين بمجال العمل وبالهيكلية الذين يجب أن يكونوا 
قادرين على بيان أكثر خصائص الهيكلية اعتماداً على عرض 
النظام (مثلاً خاصية قابلية التعديل) وتبرير ذلك. 
الذين يستخدمون هذه العروض للتحقق من حجم ودرجة 
تعفد مهام العمل بحيث يكونون قادرين على تحديد مستوى 
التحليل الملائم و تخصيصه لفرق عمل معينة. 

- المختص بالتواصل الذي يعرف الطريقة الأفضل لتنظيم وثائق 
التعاون الفنية كمشروع 1/114 (انظر الفصل الثاني عشر من 
هذا الكتاب). 
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مور الشينيعة المسؤول ظضن صيانة الأمندارات العديي: 
والإصدار الحالي من الوحدات المنظمة في جموعات وظيفية 
ومتناسقة يمكن رزمهاء وهو قادر على إنتاج إصدار حالي 
من النظام. 

فاحصي النظام الذين يستخدمون الوحدات لإنشاء حالاات 
الاختبار وتتفيذ الاختبار اللازم. 


3-5-2-5 المقارنة بين طرق العرض المختلفة 

تستخدم فرق البرمجة الموزرّعة في عدة مواقع طرقاً عديدة 
لعرض الهيكلية؛ ولتسهيل ذلكء لا بد من توفّر نموذج منطقي 
مشترك للهيكلية لدى هذه الفرق. ومن المهم ضمان دقة وسهولة 
التصفح والتنقل بين هذه العروض في جميع مراحل المشروع. وهذا 
يعني ضرورة تتبع عمليات تنفيذ العروض وعروض الوحدة ووثائق 
التصميم القنية التي انشعك لاحقا فى مرخلة النطويز.. هذا أمر 
ضروري لسببين: 


تتيح المجال لمدير المشتزوع والمختضن بالهيكلية والمختص في 
مجال العمل الالتقاء معاً وفهم الروابط» ليس فقط بين 
مكوّنات العروض وحسب بل خلال العروض نفسهاء 
وهذا يصبح أداة مهمَّةَ أثناء تخصيص التنفيذ أو وحدات 
التنفيذ في مواقع البرمجة النائية ببدف تقليل الروابط خلال 
هذه المواقع. 

تستطيع فرق البرمجة التي تعمل عن بُعد النظر إلى العرض 
الذي يعتبر أساس خطة البريحة وتتبع تخصيص وحدات 
البرمجية من خلال عدة عروض لفهم مهام العمل المخصصة 
نهما شاع ودلا مك حابم فى طر ني فال 
ودقيق للعمل الذي يجب إنجازه في كل فترة برمجية تكرارية. 
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6-2-5 مراجعة الهيكلية 


نوصي بإجراء مراجعات رسمية ‏ واحدة على الأقل - قبل 
نهاية مرحلة التطوير. نستخدم أسلوباً يعتمد على طريقة تحليل 
مبادللات الهيكلية المتبع في معهد هندسة البرمجيات وهذا 
الأسلوب يعرف ب (1421) (2001 ,[21 غه] 5أسعصهو01). ففى 
حين أننا لن نعيد خطوات أسلوب (41831) هناء لكن نرى أله 
من الضروري أن نقوم بالمراجعة بنفس الطريقة كما في ورشة 
عمل متطلبات الهيكلية المهمة. بمعنى اخرء قد ترغب في مراجعة 
الهيكلية في ما يخص أهداف المشروع وقدرة الشركة على تطوير 
الهيكلية. لعمل ذلك» عليك أن تُشرك أصحاب المصلحة في ذلك 
على نطاق واسع. يتم دعم وتعزيز هذه العملية عن طريق تنفيذ 
أعمال ورشة عمل لأهم المتطلبات من ناحية الهيكلية. وهذا 
يساعد أصحاب المصلحة في فهم ما يتوقع إنجازه والأهداف التي 
أعلنت عنها الشركة ومتطلبات الهيكلية المهمة التي تم تحديدها 
والغرض من الاجتماعات التي يتم عقدها. وتختلف مخرجات 
عملية المراجعة» إذ قد تكون عبارة عن المخاطر والأمور غير 
الخطرة والمبادلات والنقاط الحساسة فى الهيكلية. لمزيد من 
المعلومات حول هذه العملية» الرجاء الك له أع] مامعمعات) 
(2001. 


3-5 | لملخص والاستنتاجات 

عُنِي هذا الفصل بأمور هيكلية النظام المرتبطة بمشاريع تطوير 
البرمجيات الموزّعة المراكز. من المهم تحسين الهيكلية بحيث 
يسهل توزيعها على فرق العمل التي تعمل في عدة مناطق 


141 


الأخذ فى الاعتبار إمكانيات أعضاء فرق العمل وقدراتهم على 
العمل مع بعضهم بعضاً ومستوى السيق المطلوب بينهم. ستساعد 
فى إنشاء وحدات العمل. كما تساعد عملية تحليل الروابط فى 
تحديد المسارات الحرجة» وبالتالى جدولة عملية برمجة هذه 
الوحدات. وبما إن الهيكلية هي أمر حرج لنجاح المشروع ‏ 
تخسوصا إذا كان الع موزها فى غدة ناطق معرافية يتوت 
مراجعتها مع أصحاب المصلحة. كما يجب توثيقها لمساعدة فرق 
العمل ذوي العلاقة على فهم الهيكلية ومشاركة الرؤى ذاتها. وكما 
أكدنا في الفصل الرابع من هذا الكتاب» فإن الهيكلية ذات الجودة 
العالية تقطع شوطاً طويلاً نحو إنتاج منتج عالي الجودة. تساعد 
التقنيات الموضحة فى هذا الفصل فى التركيز على الامتياز التقنى 
في مراحل مبكرة من دورة حياة تطوير البرمجية. 


4-5 أسئلة للمناقشة 


1. ما هو المغزى من الهيكلية والهيكل التنظيمي للشركة في 
مشاريم تطوين البرححبات المور ع" المزاكز؟ 
المورّعة المراكز لمتتج بريجي؟ 

3 صف بعض طرق العرض المستخدمة لتوثيق الهيكلية 
بالإضافة إلى تلك المعرفة فى هذا الفصل. ما هو مغزى هذه 
الطرق» إن وجدت,. بالنسبة إلى مشاريع تطوير البرمجيات 
المورّعة المراكر؟ 
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تحليل المخاطر 


عندما كان جو يعمل في مشروع (845)» شارك في دورة 
تدريبية حول إدارة المخاطر. نصح المحاضر فريق إدارة المشروع 
بالتركيز على بعض المخاطر التي قد يكون احتمال حدوثها كبيراً وقد 
تؤثر بصورة سلبية في المشروع. فكر جو بكافة المخاطر المحتملة 
المركظة (بسطويو لتر يضاف المواعة الفراكة على فى كير نكن 
شركته تفتقر إلى الخبرة الكافية فى مجال الاستعانة بمصادر خارجية» 
أدرك أن هناك الكثير من الحا المقلقة التي دن في 
المشروع. 


بالنظر إلى درجة تعقيد مشروع (845)» كان من الواضح وجود 
العديد من المشاكل المحتملة. في واقع الأمرء كانت المشاكل كبيرة 
بحيث تهدد نجاح المشروع. هل يوجد وقت معين تعالج فيه هذه 
القضايا؟ إذا كانت الإجابة بالإيجاب». هل يمكن اتباع استراتيجيات 
للحد من احتمالات تحقق هذه المخاطر؟ 
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نناقش فى هذا الفصل إدارة المخاطر المتعلقة بتطوير البرمجيات 
الميودطة سردي سعايه عد «دارة الجتعاط كن "مشاريع خطوير 
البرمجيات الموزعة المراكز مع إدارة المخاطر في مشاريع البرمجيات 
المجمّعة التقليدية في العديد من النواحي» غير أن هناك بعض 
الاعتبارات الخاصة. نسلط الضوء هنا على طرق اختلاف إدارة 
المخاطر في مشاريع البرمجيات الموزّعة» حيث نفترض أن القارئ 
لديه معرفة عامة عن إدارة المخاطر. 


إن إدارة المخاطر هي المسؤولية الأساسية لمدير المنتج (أو 
البرنامج). وقد يساعده في ذلك موظفو ضمان الجودة أو خبراء 
العمليات» لكن جميع أفراد فريق العمل مسؤولون عن تحديد 
المخاطر المحتملة والإجراءات اللازمة للحد منها. يجب وضع خطة 
لإدارة المخاطر أثناء مرحلة التطويرء لكن تنفيذها ومراقبة تطور 
العمل بها تتم بعد توثيق أول مخاطرة. 


1-6 تمهيد 

نقدم في هذا القسم تمهيداً عن إدارة المخاطرء ونناقش مصادر 
المخاطر المرتبطة بمشاريع تطوير البرمجيات الموزّعة المراكز 
خصوصاً. هذه المعلومات غير مترابطة فى بعض المعانى فى هذا 
الكتاب» إذ نناقش في كل قسم لمان د (أي المخاط تفط 
بالأنشطة قيد النقاش. كما نناقش طرق تحديد وعنونة هذه القضايا 
(تحقف جهدة المتخام ): 

لماذا خصصنا إذاً فصلاً خاصاً لإدارة المخاطر؟ ألم نتناول هذه 
القضايا بشكل كافٍ فى هذا الكتاب؟ تعتبر إدارة المخاطر نشاطأً 
حرجاً في إدارة الشاريم بذانيا] معيف تعن أعداف العم المعتة 
لاتخاذ القرارات المتعلقة بإدارة المخاطر. غالباً لا يقوم المديرون 
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بعمل شىء سوى إدارة المخاطر بطرق عديدة. وفى هذه الحالة» من 
الحمقى بوكو مليسدية متقطدة لمراقنة ملا دوه إكازة الدخاطر 
وأين يجب أن يتركز الاهتمام الإضافي. ثمة أمور محددة في مشاريع 
تطوير البرمجيات الموزرّعة المراكز لا تكون واضحة إلى أن يظهر 
تأثيرها في المشروع. لقد شهدنا من قبل العديد من المشاريع التي 
فشلت لأنها لم تلقّ الاهتمام الكافي مبكرا بما يكفي لتفعيل عوامل 
معينة في مشاريع تطوير البرمجيات الموزرّعة المراكز. لقد ذكرنا هذه 
العوامل في هذا القسم. 


1-1-6 ما هى المخاطر؟ 

هناك تعريفات عديدة للمخاطر كمعظم المصطلحات الفنية. 
أساسياء المخاطرة هى احتمالية المعاناة من الخسارة 6ه] 66]ه:ه2) 
(21.[1,1990. الأمر الع هنا هو إدراك أن هناك حالة من «عدم 
التأكد» من أن الخسارة ستسبب نوعاً من المعاناة. إذا حدثت الخسارة 
فعلاً أو في حالة التأكد من حدوثهاء لا يمكن القول إنك تتعامل مع 
مخاطرة ‏ بل إنك تتعامل مع مشكلة. بالنظر إلى النقاش المفتوح 
حول مشروع (08485).» لا نقوم بوصف المخاطر بل نصف المشاكل 
التى حدثت. المشاكل تكون مخاطر فى المراحل المبكرة من 
لوو وقبل التأكد من حدوث هذه المشاكل (أي عندما كانت 
مجرد احتمالات). في مشاريع البرمجيات» تكون الخسائر التي قد 
تسبب معاناة على شكل زلات في الجدول الزمني للمشروع أو 
تكاليف زائدة أو جودة المنتج النهائي ضئيلة أو فشل المشروع كاملا. 
إضافة إلى كافة القضايا التقليدية التي يمكن مواجهتها في المشاريع 
المجمعة التقليدية» تواجه مشاريع تطوير البرمجيات الموزعة المراكز 
قضايا معينة متعلقة بالتنسيق وحل المشاكل وتطور المتطلبات أثناء 
التنفيذ ومشاركة المعرفة وتحديد المخاطر. تعتبر أساليب تحديد 
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المخاطر ومراقبتها في تطوير البرمجيات المورّعة المراكز أقلَّ فعالية 
وينعين زيادتها: ستناقش ذلك يمريذ. من التفصيل لاحقاً. 


2-1-6 دورة حياة المخاطرة 
في المشاريع التقليدية» يمكن تعريف مراحل المشروع والأنشطة 
المرتبطة بها كدورة حياة المخاطرة. حدد معهد هندسة البرمجيات 
دورة حياة المخاطرة (1996 ,31.1 غ»] ء18ه:120) بأنها تتضمن الخطوات 
الآتية : 


© التعريف: البحث عن المخاطر وتحديدها قبل أن تصبح مشاكل. 
© التحليل: تحويل بيانات المخاطرة إلى معلومات لاتخاذ 
القرارات» وتقويم تأثير المخاطرة والاحتمالية والجدول 
الزمني وتصنيف المخاطر وتحديد أولويات المخاطر. 
© التخطيط: ترحمة معلومات المخاطرة إلى قرارات واتخاذ 
الإجراءات التخفيفية (في الوقت الحالي وفي المستقبل) وتنفيذ 
هذه الإجراءات . 
© المتابعة: مراقبة مؤشرات المخاطرة واتخاذ الإجراءات التخفيفية. 
© التحكم والسيطرة: إجراء التصحيحات اللازمة لتعديل 
الانحرافات عن خطط التخفيف من حدة المخاطر. 
© الإبلاغ : توفير المعلومات وردود الأفعال الداخلية والخارجية 
لأنشطة المخاطر والمخاطر الخحالية والمخاطر الناشئة. 
يتأتى فهم دورة حياة المخاطرة المعرّفة أعلاه من كونها مستمرة. 
وهذا يعني أنك لا تحدد المخاطرة في بداية المشروع وحسب» بل 
إنك تحتاج إلى وجود اليات لتحديد وتحليل المخاطر والتخطيط لها 
ومتابعتها ومراقبتها والإبلاغ عنها باستمرار طوال فترة المشروع. وقد 
تتغير الأساليب بتطور المشروع. فعلى سبيل المثال» قد تكون 
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استخدمت طريقة تشخيص أكثر تنظيماً في مراحل مبكرة من دورة 
حياة المشروع لتحديد المخاطر الكبرى أو الموضوعات المرتبطة 
بالمشروع والتي لها آليات مختلفة أخف وزناً لتحديد المخاطر 
الجديدة التي تنشأ بتطور المشروع. سنشرح لاحقاً بعض الأساليب 
المنظلية المستهدءة لتعدين المخاطر: والسطرة أعلها: 


3-1-6 المخاطر في سياق مشاريع تطوير البرمجيات المورّعة 
المراكز 
تتضمن مشاريع تطوير البرمجيات الموزرّعة المراكز بعض 
الاعتبارات الخاصة كما ذكر سابقأء والتى تكون غالبا فى صلب 
القن اق عرس بسنا القع الوق فى كا ال اين اوسن اه 
القضايا 000 ١‏ ْ ْ 


1-3-1-6 التنسيق 

من خلال خبراتنا في مشاريع تطوير البرمجيات الموزّعة 
المراكزء نجد العديد من الصعوبات والمشاكل المرتبطة بالتواصل 
والتنسيق. لا يدرك القائمون على هذه المشاريع مدى أهمية التواصل 
غير الرسمي (المحادثات التى تجري بين الموظفين أثناء استراحة 
اذاه اورف التؤماكة) ودورها لسري فى لمرو الحتيف المدولة 
لفيا ارح أكر كع مليدكة وير المرتضيات السريعة ذلك 
ووظفته عن طريق مأسسة الممارسات التي تشجع وتعزز التواصل 
المخصص (كالبرمجة المزدوجة ووجود العميل في موقع البرمجة 
وقاعات العمل المفتوحة. وغير ذلك). في مشاريع تطوير البرمجيات 
السريعة» هناك فرق عمل موزعة في عدة مناطق جغرافية» وذلك من 
شأنه أن يجعل هذا النوع من التنسيق صعباً ومكلفاً. حيث لا تتوفر 
العديد من الإشارات الخفية التي تساعد الأشخاص على فهم بعضهم 
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بعضاً والحصول على الآراء والانطباعات. وتكون النتيجة النهائية 
لذلك صعوبة توفّر فهم مشترك لمهام معيّنة بين أفراد هذه الفرق 
المتباعدة. كما يصعب قياس مقدار الفهم المشترك المكتسب. في 
مشروع (8485)» كان هناك عدد كبير من الافتراضات عن المعلومات 
التي تحتاجها فرق العمل التي تعمل عن بُعد لزيادة الإنتاجية (مثلاء 
ااستزودهم بمواصفات البرنامج فقط وهم سيّسورّون بذلك»), ولم 
يكن هناك آلية رسمية لتقويم فعالية الآليات التي استخدمت (وثائق 
التصميم). 

أظهر البحث (وخبراتنا تتفق مع هذه النتائج) أن المهام المنقّذة 
في مواقع العمل تستغرق وقتاً أطول من المهام التي تنفذ في موقع 
واحد (فى الدراسة». ذكر أنها أطول بمرتين ونصف المرة) طاءاوم:ه11) 
أء] 00 2003 رنتكاء740 لصة اعاوطاءع8 :1999 ,1م1101 امه 
(2001 ,21.[1. إن ما يبدو أنه يؤخذ بالحسبان لهذه الفروقات هو أن 
هناك زيادة في عملية التنسيق المطلوبة في المشاريع الموزرّعة؛ إضافة 
إلى ذلك». هناك زيادة فى عدد المشاركين اللازمين لإنجاز المهمة فى 
إعداد تطوير التوسيانه المورّعة المراكز ,7عاصة0 لصهة ءاور 1]) 
(2001 ,[.له غع] اعاوطمعط :2003 ركبكاءه84 لصهة اعاوطعع2 :1999. 
وعذه الشقيقة ظر ترفك بها فى مشاريم تطرير' الترمكنات الموزعة 
المراكز. ويتم عادة تجاهل احتمال وجود صعوبات في عملية التنسيق 
أو يقلل من شأنهاء كما لا يدرس التأثير المحتمل لهذه الصعوبات 
في المشروع بعمق كافٍ. 

إذا نظرنا إلى الدور الذي يلعبه التواصل في تطوير البرمجيات 
نظرة عن قرب لتحديد سبب صعوبتها في مشاريع تطوير البرمجيات 
الموزرّعة المراكزء ستبدأ الرؤية في التشكل حول سبب وجود هذه 
الصعوبات وأنواع الإجراءات الى كه اتباعها للتخفيف من حدة 
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المخاطر. وكما قيل» فإن التواصل غير الرسمى وغير المخطط له أمر 
مهم في عملية تطوير البرمجيات (1994 ,[لة أ6] لارء). تؤدي 
النقاشات التي تدور بين أعضاء فريق العمل أثناء إعداد القهوة أو 
حول مائدة الطعام وقت الغداء دوراً من في مشروع البرمجة. إذ 
تساعد هذه الأحاديث على توثيق العلاقات الشخصية وتنمية مهارات 
لامكل وتساعد في إيصال الأنشطة والمهام بين الأفراد المشاركين 

في المشروع. أثناء هذه النقاشات» قد يُكشف النقاب عن افتراض 
وجود نزاعات أو تفسيرات خاطئة للأمور أو الروابط بين الأعضاء. 
كما إنها تساعد في إنشاء شبكة اجتماعية يمكن الإفادة بها للحصول 
على إجابات للاستفسارات وإيجاد حلول للمشاكل التي قد يواجهها 
العمل. إن معرفة إلى من يستطيع المرء اللجوء أمر ليس باليسير في 
المشاريع الكبيرة» لكن وجود شبكة اجتماعية مُمَأسسة جيداً يساهم 
في الحد من الوقت الذي قد يحتاجه أحدهم في محاولة العثور على 
الشخض' الحفاستن: وصية العئور على هذا التشخص ‏ سكون أمو 
الوصول إليه أو إليها والقدرة على التواصل بفاعلية وكفاءة أسهل إذا 
كان هناك علاقات جيدة معه (2003 رقناكءاءه21 0صة اعاو1»26]) . 


بانتشار تقنيات معينة مثل الرسائل الفورية وبرامج الدردشة 
المتنوعة» أصبح أمر نشر التواصل غير الرسمي أسهل من ذي قبل. 
وهذه الحقيقة تعني أن التواصل غير الرسمي وغير المخطط له صعب 
للغاية ولا عدف عادة بين المواقع. لكا نان العثور على الشخص 
أو الأشخاص المناسبين والتنسيق معهم يستغرقان وقتاً أطول لبيان 
مدى أهمية العمل خلال مواقع عديدة. لنأخذ المثال الآتي كحالة 
شائعة تحدث أثناء عمليات الدمج والتكامل : 


نحن نؤيد الإصدارات الهندسية الشهرية» التى تتضمن اختبارات 
للبناء والتكامل. وليس من المستغرب اكتشاف مشاكل أثناء هذه 


151 


العملية» وتسجيل وجود خطأ أو خلل في نظام تعقب الأخطاء 
بالإضافة إلى تعيين شخص أو فريق مسؤول. يقوم «خبير البناء» 
بتخصيص المهام على أساس الافتراض (أو التخمين) في ما يتعلق 
بمكان وجود المشكلة. حينها يكون على الشخص الذي تم تعيينه 
متابعة الموضوع ليكتشف مصدر المشكلة. وقد لا تكون الشيفرة 
البرمجية التي يتم تعقبها خاصة بالشخص الذي تم إسناد المهمة إليه» 
وعادةً ما يكون هناك حاجة للتنسيق مع أشخاص آخرين من مواقع 
اخرى. 


أولا» يفط" أذ كن تاك مدرقة بسيطة عع الشخضن' المتايست 
اللا يله الثر اص يه ,رحيتها زياذا اللاتكصن العو اضال نبي 
بعض التنسيق المناسب للإجابة عن السؤال. وفي الأغلب يكون لدى 
الشخص الثاني مهام أخرى ولن يعطي هذه المسألة نفس الأولوية 
التي ينبغي على الشخص المسؤول أن يوليها إياها (ويصبح هذا الآمر 
أقرب للواقع عندما يكون الشخصان غريبين عن بعضهما بعضا)؛ ما 
يزيد من مقدار الوقت الذي يستغرقه الحصول على التفاعل الكافي. 


وبالإطلاع على هذا الوضع الشائع يتضح كيف أن التنسيق قد 
يستغرق وقتاً أطول عبر المواقع المختلفة. 


يكون عامل التنسيق أكثر حسماً في المشاريع التي لها متطلبات 
وعناصر تصميم مبهمة أو غير ثابتة 2800 ]لها :1997 بطاتةةطله0) 
(1995 ,5266165 ولكنه يمكن أن يشكل مشكلة في أكثر المشاريع 
استقراراً أيضاً. 

سنناقش لاحقاً الاستراتيجيات المتنوعة للمحاسبة والمراقبة 
والتقليل من المخاطر المصاحبة للتنسيق والتواصل عبر المواقع. 
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2-3-1-6 تنسيق الهيكلية 

كما تم تناول الأمر في الفصول المتعلقة بهيكلية البرمجيات» 
يمكن أن تنشأ المشاكل بسبب التنسيق الخاطئ بين الأنظمة قيد 
البرمجه والمؤسسة التي تقوم ببرمجة تلك الأنظمة. ثمة نهج بسيط 
خاص بتوزيع العمل يوضح هذه النقطة. فقد تم البدء بمشروع لتطوير 
برنامج بالغ التعقيد. 


كان هذا البرنامج عبارة عن حل مضمَّن له قيود مفروضة على 
الموارد ومتطلبات صعبة حقيقية. إضافة إلى ذلك» كان لهذا البرنامج 
احتياجات معقدة متنوعة» حيث كان من المفترض أن يدعم مجموعةً 
واسعة من المنتجات. أثناء عملية التصميمء قام المصممون بعمل 
راع اميفو ا سوبي حل ينض علق _المكوكالة' لعاول التحموم: 
المركبة من المتطلبات الموجودة في النظام. يتم إسناد الأعمال 
وتخصيصها بغض النظر عن الحواجز الجغرافية بين الأفراد. فهم 
يقومون بإسناد الوحدات حسب الوحدة التنظيمية المسؤولة عن تلك 
الوظيفة. وقد صدف أن تكون تلك الوحدات (وبالتالى الفرق المسندة 
لتلك الوحدات) موزرّعة عبر خمسة مواقع في عدة بذاك وو 

تتطابق هذه المواقع مع مختلف تملكات في السنوات الأخيرة» 
وبالتالي ليس من الضروري أن يكون هؤلاء الأشخاص قد عملوا معا 
في الماضي. وقد تم تسليم البرنامج في النهاية» ولكنه استغرق وقتاً 
أطول بنسبة 120 بالمئة من المتوقع» وتجاوزت الميزانية المخصصة 
بما يقارب 80 بالمئة» ناهيك بمشاكل في الجودة (وهو السبب 
لبان اعفار الفادحة فى الأرباع ا 0 5 

يعترف العديد من المشاريع بأن الحدود الجغرافية ينبغي أن 
تكون مرآة لحدود النظام بطريقة ماء فالأمر أكثر تعقيدا من هذا. 
يكون الأمر الشائع أن وحدات عمل النظام تحتاج إلى التفاعل بطريقة 
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ما (لإدراك مجمل متطلبات النظام). وهذا التفاعل يعني نوعاً من 
التنسيق بين الفرق التي تعمل على برمجة وحدات العمل. السؤال هنا 
هو: هل يمكن أن نتوقع من هذه الفرق أن تقوم بالتنسيق الكافي 
لتحقيق هذه التفاعلات كما هو متوقع في المدى الزمني المطلوب؟ 
في حين أنه لا يمكن الإجابة عن هذا السؤال بشكل ملموسء. 
سوك : سد لدابت المدرقدة هبنو لانن قن ماق 


3-3-1-6 عدم التأكد والتغيير 

يوجد غموض وعدم تأكد بدرجات متفاوتة في كل مشروع. 
فالمتطلبات والتصميم والمظاهر المختلفة والممارسات الإدارية 
والعمليات التنظيمية جميعها مجالات قد تكون عرضة لعدم التأكد 
والغموض والتقلّب. ويمكن أن يشكل عدم الاستقرار في هذه 
المجالات اضطراباً في أي عملية تطوير برمجيات - ولكن أثر هذا 
الاضطراب يكون أكثر وضوحاً في مشاريع تطوير البرمجيات المورّعة 
المراكز. ويتناول هذا القسم الفرعي باختصار هذه المجالات المتعلقة 
بالغموض وأثرها في مشاريع تطوير البرمجيات الموزرّعة المراكز. لا 
يزال يتعين علينا العمل على مشروع مجدول بوتيرة هادئة مع الأخذ 
بالحسبان كافة القضايا والمهام المحددة فى الجدول اومن وكافة 
المهام المخصص لها الوقت الكافي لإنهائها (على الرغم من أنه 
تإمكانا حميها أن نأمل ونحلم). تكون الجداول الزمنية غالباً 
مضغوطة والفترات الزمنية لا تستوعب كافة المهام والمشاكل المختبرة 
بشكل كافٍ. وليس من غير المألوف مواصلة المشروع بمهمة زمنية 
«مثل إشراك فريق بعيد) من دون استكمال كافة الأنشطة المسبقة 
بشكل كامل. وهذه حقيقة في مشاريع البرمجيات في وقتنا الراهن. 

إن عدم التأكد هو أيضاً حقيقة واقعية في مشاريع البرمجيات. 
ومن المهم تحديد واستيعاب عدم التأكد في كافة المشاريع» ولكنه 
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أمر حتمي بشكل خاص في مشاريع تطوير البرمجيات الموزرّعة 
المراكز. وبسبب الطريقة التي تتفاعل بها الفرق والديناميكية التي 
يمكن أن تتطور بها المشاريع بسرعة» قد نفقد السيطرة على حالات 
عدم التأكد (الذي قد يكون على شكل مظاهر مبهمة في النظام أو 
مواصفات مفسرة بشكل خاطئ أو بنود محددة بشكل سيى) ما يسبب 
انهيار المشروع. وتظهر خبرتنا في مشاريع تطوير البرمجيات المورّعة 
المراكز أن عدم التأكد يمكن أن يؤدي إلى فرق عمل غير منتجة أو 
محبطة. ويحدث هذا عندما تضطر الفرق إلى إعادة العمل بشكل 
جوهري دون أن يكون هناك تقصير من طرفهم أو وضع افتراضات 
للتقدم. وينطبق هذا الحال أيضاً عندما تكون الفرق عاطلة عن العمل. 
الأمر المهم هو أنه ينبغي الاعتراف بحالات عدم التأكد صراحة 
واستيعابها في مشاريع تطوير البرمجيات المورّعة المراكز. 


2-6 إدارة المخاطر في مشاريع تطوير البرمجيات الموزّعة 
المراكز 

نبدأ في هذا القسم بمناقشة تفصيلية دقيقة عن كيفية تحديد 
المخاطر والحد منها في مشاريع تطوير البرمجيات الموزعة المراكز. 
ونصف الأنشطة التي قمنا بتنسيقها بتفصيل أكثر. 


1-2-6 تحديد المخاطر 
هناك عدة طرق لتحديد المخاطر في المشاريع التقليدية. كما إن 
هناك مناهج تشخيصية مثل تقويم مخاطر البرمجيات (51878) 
(1999 ,[.له أع] كمنتط 1 17111ا) ا (2000 ,[.1ه أع] ممصحعميكا) لالذا'فض 
ويمكن لأعضاء الفريق إبلاغ الإدارة عن المخاطر من خلال 
الاجتماعات الدورية أو تقديم التقارير. جميع هذه الطرق صالحة 
فسن اللاركظة: ف «ملقاعع طون الرمتعيايك الجر زع مركن ابا 
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ولكنها قد لا تلقي الضوء على المخاطر الخاصة المصاحبة لعملية 
التنسيق. وتعتمد درجة المخاطر التي يتعرض لها الجدول الزمني 
والميزانية وجودة المنتجات التي تنبثق عن توزيع بعض التطوير على 
النظام الذي تقوم ببرمجتهء والسياق الذي سيتم تطويره فيه» وسمات 
الفريق الذي سيقوم بالتطوير. أما الخطوة الآولى في فهم المخاطر 
الكامنة في مشروع ماء فتتمثل بالتبصر في الشركة والنظر إلى خيارات 
التوزيع في النظام. 

لمتخدم ميج المتتخيضي الطر يريما عي ولف لطر 
لمشاريع تطوير البرمجيات الموزرّعة المراكز. يصف هذا الملف 
قدرات الشركة التي ستقوم ببرمجة النظام» واحتياجات التنسيق 
المتضمنة من قبل النظام الذي سيتم برمجته» وتقويم درجة عدم 
التطابق. يلقي عدم التطابق هذا الضوء على المجالات التي تنطوي 
على مخاطر عالية. ويكون هذا التقويم مدخلاً لعملية التخطيط والتي 
تتضمن تحديد الاستراتيجيات المناسبة للحد من درجة التعرض 
للمخاطر. 


1-1-2-6 تحديد القدرة على التنسيق 

هناك ثلاثة مكوّنات لطريقة التشخيص هذه: (1) تحليل ترابط 
النظام (تم وصفه في الفصل الرابع من هذا الكتاب). (2) تحديد 
الخصائص التنظيمية»؛ (3) تحليل «التناسق» النسبي بين الاثنين. إن 
الهدف من تحديد الخصائص التنظيمية هو فهم القدرة على التنسيق 
بين الفرق ذات الصلة في المشروع. ويتضمن هذا فهم أمور منها: 

- الخلفية العامة عن مهارات أفراد الفرق (أو الذين يمكن أن 

تتشكل منهم الفرق) . 
- معرفة الفرق بنطاق العمل المرتبط بالمنتج الذي سيتم تطويره. 
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- تاريخ التفاعل بين الفرق (مثلاً هل قاموا بالعمل معاً من 
م 
الفصل التتظيمن :بين الفرق (مثلا هل يوحد اقيق تسلسل 
تقديم التقارير؟). 
- هل يتشاركون نفس الثقافة واللغة؟ 
تساهم جميع هذه البنود (وغيرها الكثير) في قدرة الفرق على 
العمل معاً أو تعيقه. ومن البديهي أن يتم تحديد الفئة التي تنتمي إليها 
كل خاصية. فعلى سبيل المثال» تكون عملية التنسيق أسهل إذا كان 
أعضاء الفريق يعرفون بعضهم بعضاً معرفة شخصية. وفي حال أنهم 
لم يلتقوا من قبل» ستكون العملية أكثر صعوبة. هذا وستتضح 
الصورة العامة فور تجميع هذه العوامل. هذا ليس علماً دقيقاًء بل هو 
مصمم لتقديم نظرة حيثما تكمن المشاكل المحتملة والمساعدة على 
التركيز على أنشطة الرصد. 


2-1-2-6 المشاركون 

يمكن أن يقوم بهذا النشاط أي شخص يدرك المخاطر المحتملة 
للمشروع. وباستطاعة المشاركين إجراء مقابللات فع الناس» إن دعت 
بالنتائجح لفريق إدارة المشروع. 

3-1-2-6 المدخلات 

لإجراء هذا النشاط» ينبغي أن نضع في الاعتبار الأماكن التي 
يمكن أن تتم فيها البرمجة» ومن سيقوم بتحديد أعضاء فرق العمل. 
ويمكن أن يساعد هذا التحليل الاختيار بين المواقع» ولكن لا يمكن 
إجراء هذا النشاط من دون أن يتم اقتراح مرشحين. إضافة إلى ذلك» 
من المفيد أن يكون هناك معرفة عامة عن النظام الذي سيتم إنتاجه. 
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كما يجب تحديد أي مجالات معرفة أخرى خاصة كمعالجة الصور. 
وسيكون من المفيد أيضاً إدراك مجالات الاهتمام بشكل عام 
(كمواضع السلامة العامة وأداء الزمن الحقيقي» والعمليات المستمرة 
التي تتم على مدار الساعة). 


4-1-2-6 المخرجات 

سيكون مخرج هذا النشاط عبارة عن ملف عن إمكانيات 
التنسيق في شركات البرمجة. وقد يكون هذا الملف رسمياً جداً أو 
غير رسمي حسب الحاجة» وسيتم ضمه إلى تحليل روابط النظام 
لتحديد التناسق أو عدم التطابق النسبي» حسب الحالة. 


2-2-6 الحد من المخاطر 

خلال مرحلة الإعداد» سيكون من الحكمة الحصول على بعض 
المفاهيم عن ملف المخاطر للشركة كمدخلات. سيتيح ذلك إمكانية 
التخطيط للمشروع وتوزيع العمل ووضع الممارسات مع المخاطر في 
الحسبان. هناك أمور ينبغى أخذها بعين الاعتبار للحد من المخاطر. 
أونها انيع طن طرق يي فار ارك الشركة؛ وثانياً تخطيط نواحي 
التنسيق للمشروع؛ وثالفاً التخطيط المسبق لكيفية تعديل المشروع في 
حال كانت خطة التنسيق الأولية غير كافية (المشروع لا يجري 
بالسهولة المطلوبة). وسنقوم بمناقشة كل من هذه الأمور بدورها. 

1-2-2-6 زيادة قدرات المؤسسة التنظيمية 

تذكر أنه وكجزء من المنهج التشخيصي المذكور أعلاه» فإننا 
نبحث في القدرات الموجودة في الشركة. ففي حال تم تحديد عدم 
تطابق في التسلسل» يمكن البحث عن وسائل الحد من المخاطر في 
فسحة الحل (من المحتمل تغيير تصميم النظام) أو التفكير في تغيير 
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بعض خصائص الشركة. لكل بند تم أخذه في عين الاعتبار» حيث 
لم تتلقّ الشركة (أو بعض الفرق) تصنيفا إيجابياء فكر في طرق 
تستطيع من خلالها إحداث تغيير في بعض النواحي في الشركة 
لتحسيخ هذا التصتيف+ فعلى سبيل المغال» إذا لم تكن الفرق ذات 
الصلة بالمشروع قد عملت مع بعضها بعضا في السابق ولا تعرف 
شيئاً عن أعضاء الفرق الأخرى» حينها يمكن أن تفكر في تبديل 
الأشخاص أو تنظيم الفرق لبعض الوقت أو التدريب المشترك أو 
الاجتماعات التنظيمية الدورية أو تمارين بناء الفرق أو غيرها من 
الآليات لزيادة الوعي وتحفيز الحوار بين أعضاء الفرق الأخرى. على 
سبيل المثال» يُستخدم اجتماع إطلاق المشروع خلال مشروع تطوير 
البرمجيات المورّعة المراكز لهذه الغاية. ومن الخيارات الأخرى: 

- بنية تحتية موحدة (مثال 1218 أو نطاق يصطنع التطوير). 

- ارتباط أكثر إحكاماً للممارسات الإدارية. 

- بناء أكثر تواتراً. 

- استعراض ما بين الفرق. 


2-2-2-6 وضع خطة للطوارئ 

وبما إن الأمور لا تجري دائما حسب ما هو متوقع. فمن 
الحكمة التخطيط لهذه الاحتمالية. ويعني هذا في مشاريع تطوير 
البرمجيات المورّعة المراكزء التخطيط للكيفية التي سيتم فيها تعديل 
عملية تنفيذ المشروع ومكانها. أول شيء سترغب في عمله هو 
تحديد ووضع أولوية للأبعاد التي يمكنك تغييرها بشكل معقول ضمن 
شركتك. يمكن أن تتضمن أبعاد التغيير هذه تواتر البناء وتواتر 
الاجتماعات ونوعهاء ويمكن أن تتضمن حتى موقع الفرق. كما 
ينبغي أن يكون لديك فكرة عن الأوضاع التي ستقوم بتغيير التنسيق 
وفقاً لها. هذا سيمكنك من منهج أكثر تنظيماً لتنفيذ المشروع. يمكن 
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أن يساعد هذا المنهج في ضمان الحد من الأثر السلبي لتوزيع 
المشروع في جودة عدد مرات التسليم ومواعيدها بشيء من التدبر. 


3-2-6 رصد المخاطر 

تُعتبر عملية رصد التقدم والمخاطر ضمن مشاريع تطوير 
البرمجيات الموزّعة المراكز صعبة للغاية. فمن الصعب إدراك ما 
يحدث داخل الفرق المتباعدة جغرافياً بشكل كافٍ. ففي الوقت الذي 
تتأخر فيه المنجزات أو يتم اكتشاف مشاكل تعلق بالتجردقة فمن 
المرجّح أن يكون الجدول الزمني قد عانى الكثير. وبما إن إعادة 
التركيز أو التعافي من هذه الحالات يتطلب مزيداً من الجهد والوقت. 
ومن الطبيعي أن يكون للمطورين فكرة أوضح عن الوضع الحالي 
للمشروع في أي وقت من تلك التي لدى المديرين. فالخدعة تكمن 
في جعل المشروع أكثر شفافية والسماح للأشخاص الذين يسمح لهم 
عملهم بتحديد المخاطر من رفع التقارير بشكل حر. 

هناك عدة طرق لإنجاز ذلك». أحدها عقد اجتماعات متكررة 
حيث يقوم كل عضو في الفريق بالإبلاغ عن الحالة والأمور التي 
يواجههاء كاجتماعات البدء اليومية. هذه الطريقة فعّالة» ولكن ينبغي 
التأقلم معها مع نمو المشروع. فمن الصعب الحصول على انطباع 
فعّال بهذه الطريقة عن الحالة العامة للمشروع» للمشاريع الكبرى التي 
تنطوي على عدة مواقع تطوير. 

وقد طورنا أيضاً آليات للأفراد للإبلاغ عن المشاكل التي 
تواجههم» ولكننا وجدنا أنه من الصعب دفع الأشخاص لعمل ذلك 
بشكل مسبق. ومن الآليات التي بدأنا باستخدامها وأثبتت نجاحها هي 
الاستطلاع: اللمحظم (غادة ما يكوق تعتف أسبوعي). ويستغرق: هذا 
الاستطلاع عموياً أقل من عقر دقائق لكل شخص» ويطرح أسئلة 
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عن كيفية إدراك كل شخص لتقدم المشروع». ومع من يتعاملون 
(وكيف)» وكيف يقضون أوقاتهم... إلخ. هذا يمكن الإدارة من 
الإطلاع على ملخص البيانات (وبعد بعض الممارسة) تحديد 
المشاكل بسرعة. بعض المشاكل تكون واضحة على الفور» كالتراجع 
فى معنويات أعضاء الفريق» والأفراد المنهكين فى العمل (ويكون 
هذا الأمر واقيها عندها كو هناك فلكل. من 'العقاضين الأساسية التي 
تكون مركز العديد من النواحي في المشروع)؛ عدم التفاعل بين 
الفرق عندما تتوقع أن يكون هناك تفاعل» وغيرها من الأمور. وهناك 
مؤشرات أخرى أقل وضوحاًء ولكن يمكن أن تكون مماثلة. وقد 
وجدنا أنه برصد بعض المؤشرات» تمكنا من اكتشاف المشاكل 
بشكل مبكر. وتكون هذه المؤشرات أموراً تشبه التذبذب في التواصل 
غير المفقطط اامذال تكله ل تكرن معام لازي إصدان) ودراب 
غير مخطظ فن الشقر :وقد تنكنا بفف] الاجتماعات: الشهرية للؤقارة 
ب انلو الأمعداء الى النوكزات: والوراسن المعدزة 
والمخرجات» وقد تمكنا من اكتشاف بعض المشاكل قبل أن تصبح 
مشاكل كبيرة» والتحقيق فيهاء واستباقها. 


4-6 الملخص 


تزيد المشاكل المتعلقة بمشاريع» كالتواصل والتنسيق» من 
المخاطر التي يمكن أن يتعرض لها الجدول الزمني» والميزانية» 
والعوظ قار كلانه النعظيم وسفن العادة: أن طايه المياد 
في مشاريع وقتاً مضاعفاً عن المشاريع المنظمة. ويكون للمشروع 
فرصة نجاح أكبر في حال تم تحديد المخاطر المحتملة» وتم اتخاذ 
إجراءات للحد منها أثناء سير عملية التطوير. وقد تم تناول المخاطر 
وإجراءات الحد منها في خطة إدارة المخاطر. 
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5-6 أسئلة للمناقشة 


1. صف المخاطر المرتبطة بمشروع تطوير البرمجيات الموزّعة 
المراكزء وتعريفها واستراتيجيات الحد منها. 
2. ضف كيف يمكنك وضع ملف عن المخاطر. 


المراجع 
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(الفصل السابع 


عملية وضع خطة المشروع 


زاد قلق جو عندما قام بالتحمّق من قاعدة بيانات المتطلبات ولاحظ 
أن عدد المتطلبات» بما فيها طلبات أصحاب المصالح الحالية» قد 
وصل إلى سبعة آلاف متطلب. وتساءل «كيف سيكون بإمكاننا تنفيذ كل 
هذه الخصائص» وفي نفس الوقت الالتزام بالموعد المقرر لطرح المنتج 
في الأسواق؟» يمكن القول إنه قد نجيب عن سؤال جو جزئياً وهو 
تجميع الخصائص في (إصدارات» أو «نسخ» يمكن تطويرها بشكل 
متكرّر ومن ثم طرحها في السوق عندما تصبح جاهزة. وباستخدام 
نموذج التصميم والتحاليل المهمة للمنهج. سيتمكن جو وزملاؤه من 
تحديد خطة مشروع يمكن أن تتحقق هذه التكرارات من خلالها. 

لقد وصلنا إلى قسم إعداد خطة المشروع في هذا الكتاب. نصف 
في هذا الفصل سير عملية تخطيط المشروع بينما يقدّم الفصل الثامن 
تفاصيل عن تقدير التكاليف. سنقوم بذكر كيفية إنشاء خطة مشروع لعدة 
سنوات. وسنستخدم منهج الجدول الزمنى (عتصوءعه:5 لع<هط-عصة) 


المتكرر لتحقيق برمجة متزامنة في مواقع البرمجة والتطوير العديدة 
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المورّعة في عدة مواقع حول العالم. وبما إن التأخر في تسليم نماذج 
البرمجيات يحدث حتى في أفضل مشاريع البرمجيات» فسنناقش 
استراتيجيات التعامل معها فى بيئات البرمجة المتزامنة الموزّعة. 
1-7 تخطيط المشروع: لمحة عامة 

يقدم الشكا 1-7 لمحة مبسّطة عن الأن* نشطة المتضمنة في 
مرحلة التخطيط للمشروع. ففي حين يظهر الرسم الأنشطة على أنها 
متسلسلة إلى حد كبير»ء غير أنها لا تكون تكرارية وحسب بل 
ومقسّمة في مراحل المشروع. ويعتمد تنفيذ هذه الأنشطة على 
تفاصيل عمليتك الخاصة لدورة حياة البرمجة. ومع هذا سنقوم بتقديم 
إرشادات حول هذا الموضوع في الفصل الثامن. 


خطةٌ إصدار الخصائص 


نت :لموذع التصميم سا وضع خطة البرمجة تقدير التكلفة البيكلية ل 


خطة المشروع تقدير التكلفة 


1 1 
الشكل 1-7: مخطط عمل تنفيذ المشروع 
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تبدأ عملية التخطيط لإصدار خصائص النظام بتعيين «حزم» 
خصائص النظام التي تشكل الحلول القابلة للبيع. نسمي هذه العملية 
خطة إصدار خصائص النظام. وحسب احتياجات نظامك ومدى 
تعقيده» فيمكن أن يكون هذا أداة منفصلة أو لا يكون» ويمكن حينها 
إعطاء الآولويات لهذه الحزم. وعادة ما يقوم مدير المنتجات في 
شركتنا بإدارة هذا النشاط. 


وحسب الإصدارات المخططة والمحددة في خطة إصدار 
خصائص النظام والتحليل الوظيفي خلال عملية تعريف الهيكلية 
(الذي يظهر على شكل نموذج تصميم في الشكل 1-7)» يمكن 
تحديد النماذج المطلوبة لتحقيق هذه الخصائص. وبتطور التصميم» 
يمكن تحديد مهام خاصة لفرق البرمجة. وبإمكاننا أن نبدأ بإسناد هذه 
المهام باستخدام خطة إصدار خصائص النظام والتحاليل المهمة 
للمنهج (المذكورة في الفصل الخامس من هذا الكتاب). وتعتبر هذه 
الأنشطة غاية في التعقيد ومقترنة بأنشطة أخرى مثل هندسة المتطلبات 
وتعريف الهيكلية. ومن غير المحتمل الحصول على معلومات واضحة 
المعالم قبل البدء بعملية التخطيط» لذا فعادة ما يتم وضع خطة 
مشاريع أولية رفيعة المستوى وتقدير التكاليف. ومن ثم يتم تنقيحها 
لاحقاً بشكل متكرر. وسنقوم في الفقرات والفصول القادمة بتقديم 
مزيد من التفاصيل عن هذه العمليات وطرح أمثلة كذلك من الواقع. 


2-7 إعداد خطة إصدار خصائص النظام 


يتضمن إعداد خطة إصدار خصائص النظام حزم الميزات في 
إصدارات خارجية مخطط لها للنظام. تقع مسؤولية هذا النشاط عادة 
على عاتق مدير المنتج. وتحتمل هذه المسميات الوظيفية أكثر من 
معنى وتختلف من شركة لأخرى. ولكن المهم أن هذا الشخص 
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يكون عادة مسؤولاً عن تحديد الخصائص التي ستتيح بيع المنتج في 
السوق ويكون لديه رؤية في ذلك الشأن. وسيكون هذا النشاط 
تكوازيا احفر الغ دو مكتيل المسترعة المتل هن القصاتمق 
الأولية على الإطار الزمني أو الجهود المتضمنة في عملية البرمجة 
وقافة الحؤافه: النجالية ر اله التجانة الندية” المكر 1 ريفكة 
وضع خطة ترحيل للتخلص من المنتجات القديمة بالاشتراك مع خطة 
إصدار خصائص النظام. وأحيانا» يمكن تجزئة السوق بحيث يكون 
بالإمكان بيع المنتجات القديمة والجديدة معا حتى تبني المنتجات 
الجديدة مجموعة خصائصها. وفي مرحلة زمنية معينة ينبغي تغييب 
الممخاكا لماي ذاد لنت نيا النتر يق ين قلق ١‏ 

إن هدف هذا النشاط هو تحديد الحد الأدنى من مجموعة 
الخصائص التي يمكن بيعها في السوق. ويعرّف هذا الحد الأدنى من 
مجموعة الخصائص على أنه الإصدار الآول» ويتم حزم الخصائص 
المتبقية في إصدارات لاحقة. 

ويوضح الشكل 2-7 مثالاً على خطة إصدار خصائص النظام» 
مستنسخة من 2002 ,اونان:8). في هذا الشكل يكون اسم واضع 
الجدول الزمني هو اسم المثال على مجموعة الخصائص التي سيتم 
برمجتها. الميزات المدرجة على القائمة مخصصة لإصدارات متنوعة؛ 
وحيث تتطور خطة إصدار خصائص النظام» تتحلل هذه الإصدارات 
إن إصدارات هندسية داخلية» وهي تتطابق مع سكرم سبرنتس 
(2004 ,2001 ,عوط 2/تخطء5) (215لامة تمتضهة) . هذاء ويعتمد التكامل 
وخطة الاختبار على خطة إصدار خصائص النظام. 

كما يلاحظ من الشكل 1-7» فإن كلاً من هدف السوق 
والمواصفات الوظيفي هي مدخلات لهذا النشاط. ولبدء العملية 
ووضع مسودة أولية لخطة إصدار خصائص النظام» ينبغي إحراز تقدم 
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معقول في أنشطة هندسة المتطلبات وتكون النسخة الأولية من 
المواصفات التشغيلية متوفرة. بمعنى أخرء ينبغى أن تكون الخصائص 
الرئيسة لهذا المنتج محددة (انظر الفصل الثالث من هذا الكتاب). 
كما إن حتاك متطلباً فسيقا آخر لهذا التشاطء ألا :وهو هيف السوق 
الذي يصف أهداف العمل لتطوير هذا المنتج (لماذا تقوم الشركة 
بصنع هذا المنتج). وهذا يرسّخ ما تأمل الشركة بتحقيقه حين طرح 
المنتج» ويمكن أن يكون له تأثير كبير في أولويات الميزات. وحين 
إعادة تعريف خطط المشروع وخطط الترحيل» يجب إعادة النظر في 
خطة إصدار خصائص النظام للتأكد مما إذا كانت مجموعة الخصائص 
الأصلية المحددة لا تزال منطقية. 


الها 12 َك إلا 11 +12 
واضع الجدول الزمني 
لبحث في قاعدة ل 3 
وكين عن 
لأحداث المجدولة 
إنشاء جدول جديد | //ء 3 9 3 
لتعامل مع التقارير | //ه ره 
لتعامل مع الاكتساب /. /. 
لحصول على أمثل //. 
لمكتسنات 
لمجدولة 
عرض الجدول 3 5 
وتحديثها يدوياً 


الشكل 12-7 مال تفيس من نخظة إصدان اللخصائض - برتامج مزلي 
المرجع : بيرسون للتعليم » شركة مسحلة 
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1-2-7 المشاركون 
في حين تقع المسؤولية الأساسية لتطوير خطة إصدار خصائص 
النظام على مدير المنتجات». غير أن هناك العديد من الأشخاص 
المشاركين عادة فى هذا الجهد. يبين الجدول 1-7 قائمة بالمشاركين» 
ويسلّط الضوء 18 مسؤولياتهم الأساسية في ما يتعلق بهذا النشاط. 
الجدول 1-7: المشاركون في نشاط تخطيط إصدار خصائص النظام 


الوظيفة المسؤولية 
مدير المنتجات مديرو المنتجات لديهم حق امتلاك هذا النشاط. 


فهم مسؤولون عن تقديم أو تنظيم مفهوم السوق 
ومفاهيم عن المنتجات القديمة وعن المنافسة. 
كما إن عليهم توضيح احتياجات المستخدم 
النهائى. 

مصمم الهيكلية يشارك مهندس الهيكلية في هذه العملية بالبدء 
بتوفير المدخلات (كما هى فى الوقت الحالى) 
اللازمة لتنفيذ مجموعة ددة لصاف 

مهندس المتطلبات يوفر مهندس المتطلبات مدخلات فى المتطلبات 
التى تشكل خاصية معينة. وقد يكون ذلك مفيداً 
لتحَادِين نطاق مجموعة الخصائص والبدء 
بالحديث عن الجهود. 

مدير المشروع من المفيد أن يكون هناك مدير مشروع معني 
بالعملية يمكنه البدء بوضع مسودة جدول لغايات 
التخطيط . 


فكرة مفيدة: 
إجبار إدارة المنتج على تحديد الحد الأدنى من مجموعة 
الخصائص. 
من المحتمل أن تواجه إدارة المنتجات وقتاً عصيباً حين 
تحديد الحد الأدنى من مجموعة الخصائص التي يمكن 
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بيعها والتفكير في ما يخص الفترات البرمجية التكرارية» 
جنيك سيق إصدان خضائصن نظام إضافية إلى الوق 
بمرور الزمن. هذا لأن بيع منتج له مجموعة خصائص 
واسعة متوفرة في السوق أسهل. قد يتوجب على دائرة 
البرمجة ممارسة ضغط على إدارة المنتج لوضع أولويات 
لبعض الخصائص وتأجيل أخرى لإصدارات لاحقة. عادةً 
ما يكون هناك طلب مثل «أريد كل الميزات على وجه 
السرعة». وهذا يتطلب إقناع إدارة المنتجات بقيمة 
الحصول على بعض الخصائص المبكرة ومن ثم بعض 
الخصائص لاحقاً. ولعمل ذلك يتم حساب أرباح 
المبيعات المفقودة عن كل أسبوع لا يكون فيه المنتج 
متوفراً في السوق. 


3-7 تطوير خطة البرمحة 

يعطي الشكل 3-7 لمحة عن الأنشطة المتضمنة في عملية 
تخطيط البرمجة. ولا ينبغي تحديد خصائص النظام على أساس 
تسلسل برمجة النماذج (انظر إلى تحليل المسار الحرج في الفصل 
الخامس من هذا الكتاب). وبالتالي ستصبح خصائص النظام متوفرة 
ومتكاملة» حيث يتم تطويرها في نماذج فردية تمتلكها الفرق 
المورّعة في عدة مواقع. وحين تتوفر نماذج كافية وخصائص نظام 
منفذة» سيتم تحديد نسخة منتج وتوفيرها لاستخدام العملاء. وفي 
الثالث» يمكن تحديد المتطلبات التفصيلية تلقائياً لكل خاصية أو 
ميزة. وبالمثل» يمكن اشتقاق النماذج والمناهج المصاحبة اللازمة 
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لتحقيق كل متطلب تلقائياً من المتطلبات المدمجة ونموذج التصميم. 

ومع هذا فليس من السهل تحديد تسلسل لبرمجة وحدة ما. 
فينبغي تحديد الروابط المختلفة عبر النماذج» وتوفر المصادر 
المناسبة. إضافة إلى المهام المذكورة أعلاه» سيكون هناك أنشطة 
أخرى في الخطة. على سبيل المثال» في حال كان هناك نواح هيكلية 
غير واضحة المعالم حالياًء أو وجود مخاطر في ما يتعلّق بأهم 
المتطلبات من ناحية الهيكلية» قد يكون من الحكمة وضع مفهوم 
إثبات صحة النموذج بشكل مبكر. وينبغي تعداد هذه المهام وإضافتها 
إلى الجدول كذلك. 

يتم تحديد تواريخ كل مرحلة (والمشار إليها بالإصدارات 
الهندسية) في الجدول الزمني. وبالتالي يكون على كل فريق تطوير 
إصدار نسخة تشغيلية من الوحدات لِفْرّق الدمج المركزي والاختبار 
في الموعد المحدد. ويكون لكل فريق نوع من المرونة في ما يتعلق 
بخصائص النظام التي تم تسليمها. يجب أن يكون الإصدار مستقرا 
بما فيه الكفاية ليتم دمجه واختباره. ولكن في حال عدم توفر بعض 
خصائص النظامء يتم تخطيط برمجتها خلال المرحلة التالية. 

الأهم من ذلك في هذه العملية هو أن تاريخ الإصدار يجب أن 
يكون ثابتاً. فلا يمكن لأي فريق التغاضي عن تاريخ الإصدار. في 
بعض الحالات» يمكن لفريق البرمجة عدم المشاركة في الإصدار 
الهندسي (خلال عطلة محلية مثلا)» ومع هذاء يتم التغاضي في مثل 
هذه الحالة عن الإصدار ويقوم الفريق بالإصدار في التاريخ المشنت 
القادم للمرحلة التالي. المرحلة الحالي مخطط بالتفصيل. 

تكون الإصدارات المستقبلية أقل وضوحاً بوجود خطط 
المشاريع عالية المستوى. فيتم إعادة تخطيط المهام التي لم تنفذ في 
المرحلة الحالية لتنفيذ في المرحلة التالية. 
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فكرة مفيدة: 

قم باختيار تواريخ مراحل الإصدارات التي يسهل 
تذكرها. 

اختر تواريخ الإصدارات التي يسهل على فريق البرمجة 
تذكرها ‏ على سبيل المثال» اخر جمعة من الشهر. ومع 
العرئخل الشيرية الي تجري كل شبهر» ايعفاة كل فريق 
تطوير عمل إصدار هندسي في ذلك اليوم من كل شهر. 
ينبغي مراعاة العطل المحلية حين تخطيط مشاريع التطوير 
في عدة مواقع جغرافية في بلدان مختلفة. يمكن تعديل 
تاريخ الإصدار الاعتيادي بسبب وجود عطلة مهمة (أي 
في تشرين الثاني/ نوفمبر أو كانون الأول/ ديسمبر). 
ينبغي أيضاً تتبع إجازات الأعضاء الرئيسين في الفريق. 
حيث يمكن أن تقوم بعض الفرق بتخطي أحد 
الإصدارات في حال كانوا يخططون لأخذ إجازة في ذلك 
الوقت (أي خلال بعض أشهر الصيف في بعض الدول 
الأوروبية). لذا يجب توخي الحذر عن إمكانية قلب 
بعض المواسم. على سبيل الحعال حين العمل في مواقع 
في أمريكا الشمالية والجنوبية. 


إن إجراء التعديلات على الجداول الزمنية أمر حتمي» حيث 


تكون التقديرات غير دقيقة أو حين ظهور مشاكل غير متوقعة أو حين 
وجود فرق دون مستوى الأداء. وتكون الصعوبة عند محاولة الحد من 


أثر الأنشطة المعاد تخطيطها عبر الفرق. 
وبما إن الكثير من المهام مترابطة» فيكون تأخر إحدى الفرق سبباً 


في إضاعة وقت الفرق الأخرى. وفي كلتا الحالتين» سواء كان الفريق 
حقوقه بشكل سريع. من الجيد أن يكون هناك خطة طوارئ حيث يكون 
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بالإمكان نقل المهام في حال كان هناك تباين عن الجدول. لذا يساعد 
وجود تحليل المسار الحرج المناسب للنظام على تسهيل هذه العملية. 


إعداد خط البرمجة 


تت مراع اتسين ها إعداد خطة الجدول الزمني 1 تحليل المسار الحرع ب 


الجدول الزمني 


إعداد خطةٌ الفحص 
ل خطة إصبدار الخصدائص إعداك 
والتكامل 


لط 


خطة المشروع 


١ 


الشكل 3-7: مخطط عمل تنفيذ البرمجة 


فكرة مفيدة: 

تحديد المهام الطارئة. من المحتمل أن يتم تحديد مهام 
كبيرة قائمة بذاتها بعد تحديد المسارات الحرجة 
للمشروع. ينبغي الإشارة إلى هذه المهام صراحة حيث 
يمكن نقلها إلى أعلى جدول الأولويات في حال 
اضطلاع فرق العمل بأعمال أكثر من اللازم أو في حالة 
تعرضها لأن تصبح عاطلة عن العمل. 


1-3-7 المشاركون 


يكون الفريق الهندسى ستولا عه تحديد الوحدات وأساليب 
العمل والمنهجيات اللازمة لتحقيق الخصائص المحددة فى خطة 
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إصدار خصائص النظام وعن تحديد مراحل برمجة هذه الوحدات. 

عادة ما يكون هناك الكثير من التنقلات بين مصممي الهيكلية 
ومديري المشروع أو مديري المنتجات. هذا ويمكن إعادة النظر في 
خطة إصدار خصائص النظام» ومن المحتمل تعديلها وذلك بتطور 
الجدول الزمني للمشروع. بعدما يتم تحديد تاريخ الإصدار المقدذرء 
قد يكون هناك حاجة لتبديل تواريخ الإصدار والتشغيل لإنجاز 
وتحقيق متطلبات السوق المرغوب بها. 


4-7 تقدير التكاليف 


خلال مرحلة التحضيرء يتم عمل تقدير أولي بالتزامن مع 
تحديد الهيكلية. نوصي بتفكيك النظام إلى مكوّنات لا تزيد على مئة 
آلف سطر من الشيفرة البرمجية (11.008 100) والتي تحتاج إلى ما 
لا يزيد على 120 شهر عمل لبرمجتها. نحن ندرك أن هذا تخمين فى 
الأغلب (على الرغم من أنه كلما زادت حي المي الريكاية فى 
النطاق المطلوب» كانت التقديرات أفضل)» ولكنها عادة ما تكون 
خبرة جيدة بما فيه الكفاية لهذه المرحلة» ما يعني إمكانية التوقف إلى 
هذا الحد فى مرحلة التخطيط وتقدير التكاليف. وأما الهدف الرئيس 
من هذا الدرييه فهو إنسام المجال أماء رعاة المشتزوع لاتتهاذ قرار 
المضي قدماً في المشروع أو التوقف فيه» ولكنه يفيد أيضاً كمسودة 
لما سيأتي لاحقا في دورة حياة النظام. وسنقوم بشرح عملية التقدير 
شويد عن التفاصيل فى الفضا: الدامن: 


5-7 مرحلة جهود التخطيط 


تختلف مراحل المشروع العديدة من شركة إلى أخرى» غير أنه 
غالباً ما يكون هناك أربع مراحل أساسية بشكل أو بآخر (انظر الفصل 
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الثاني من هذا الكتاب). تتم عملية إعداد خطة المشروع في المراحل 
الثلاث التالية بالدرجة الأولى: 


.1 


9 


3 


مرحلة التحضير (عكقطم سمدتامءعصز عط)) : يتم فى هذه المرحلة 
الإطلاع على النظام الذي سيتم بناؤه وتحديد ما إذا كان منطقياً 
ومقبولاً في ما يتعلق بالأعمال. لتحديد مدى جدوى المشروع» 
مرحلة التطوير (©225ام 13502308© ©5)) : تتضمن بالدرجة 
الأولى تحضير هيكلية النظام عن طريق تفصيل المتطلبات 
ولطرين الفيكلية والمكسالاقة يلها عن حاولا وناء شر غة مووز 
مرحلة التنفيذ (©25ام دمناءن معدم 56)) : وتتضمن البناء 
الآولي للنظام حيث تعمل فرق البريحة بكامل طاقاتها؛ ويتم 
تسليم المخرجات بصورة دورية؛ كما تتضمن هذه المرحلة 
التقدم وسير العمل في النظام والتحكم فيه. 


تختلف الاحتياجات من الناحية التخطيطية اعتماداً على مرحلة 
المشروع والمعلومات المتوفرة. ويوفر هذا القسم من الكتاب مزيداً 
من الشرح التفصيلي عن كيفية عمل مراحل لأنشطة التخطيط. 

1-5-7 التخطيط خلال مرحلة التحضير 

يكمن الهدف الرئيس من وراء مرحلة التحضير في تحديد إذا ما 
كان المشروع منطقياً بالنسبة إلى الشركة في ما يتعلق بالأعمال أو اله 
ولعمل ذلك,» ينبغى أن يكون هناك تقدير للتكلفة ذات الصلة والفائدة 
من .يناة النظام. .كما توقش فى الفقفل: الاين عو +عطلية 'التمخطيط 
للمشروع» ويتم خلال هذه المرحلة تحديد المسودة الأولية لخطة 
إصدار خصائص النظام وتقدير التكاليف. ويعطي الشكل 4-7 لمحة 
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عن أنشطة التخطيط للمشروع خلال مرحلة التحضير. ومن المهم 
النظر في البدائل المتوفرة على الآقل في ما يتعلق ب: 
© الوقت المستغرق لإيصال المنتج إلى السوق. 
© وفرة وغنى الخصائص. 
© الحودة. 
© خطة الترحيل إلى قاعدة العملاء الحالية. 
© البنية التحتية المرتبطة اللازمة (أي» الأدوات المرتبطة المطلوبة 
لبيع النظام بكفاءة كأدوات تحويل البيانات والأدوات الهندسية 
وأدوات إعداد المخططات والرسوم البيانية وغير ذلك) . 
| 


الهدف السوقي 
| 


إعداد خطة المشروع 


إعداد خطة إصدار الخصائص 


الشكل 4-7: مخطط عمل لمرحلة التحضير 
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من الممكن تحديد استراتيجية لكيفية تحقيق أهداف العمل. 
ويجب أن تشتمل هذه الاستراتيجية على إرشادات حول كيفية عمل 
المبادلات عند مواجهة الصعاب. على سبيل المثال: 

لنفترض أن هناك شركة تقوم بإنتاج بضائع لسوق الاستهلاك. 
دورة حياة هذه السوق قصيرة حيث إن هناك تكنولوجيا حديثة تطرح 
في السوق كل ستة أشهرء إذ تذهب غالبية المبيعات وأعلى الأرباح 
للشركة التي تقدم أحدث تكنولوجيا للسوق أولاً. وتقوم هذه الشركة 
نطو 'مشتجات جد يد ومككلقة دري كيف هن القريقة) أن هذه 
المنتجات ستغيّر اتجاه السوق. في هذه الحالة» من المهم جداً أن 
تكون أول الواصلين إلى السوق. ففي حين أن الشركة لن تعترف أبداً 
بأنها موافقة على التخلص من المنتجات التى تعانى مشاكل فى 
الجودة» عندما يقتضى الأمرء غير أنها تقر أنه من الأفضل طرح 
المنتج في وقت مبكر في السوق» حتى لو كان يعاني نقصاً في بعض 
الخصائص المخطط لها وكان يعاني بعض مشاكل الاستقرار. يمكنها 
وتحديد القضايا من دون أي تأثير سلبي. 

تيح وجود هذه الخلفية لدى مدير المنتجات له استخدام هذه 
التوجيهات عند وضع خطة إصدار خصائص النظام بالإضافة إلى 
عكس فلسفته على خطة البرمجة التي ستوضع لاحقاً. لقد شهدنا 
كثيراً قيام المديرين (أو الأفراد) على المستوى المحلي بوضع 
فرضيات عمًا هو مهم (على سبيل المثال» لا يمكننا تقليص النطاق» 
ينبغي علينا تسليم كل شيء!)» واتخاذ قرارات تتناقض مع أهداف 
العمل الرئيسة للشركة. في هذه المرحلةء يمكن لمديري المنتجات 
تحديد ما الذي يكوّن المجموعة الأمثل للخصائص الأولية 
باعتقادهم, وما هو الحد الأدنى لمجموعة الخصائص الأولية» وما 
الذي بإمكانهم تغييره للتأثير في الحد الأدنى من هذه المجموعات 
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(على سبيل المثال» إذا قمنا بتغيير السوق الأولي من ”5 إلى "لا 
حينها يمكن تقديم الخصائص ”*. ”ب". "ج'؛ أو إذا قمنا بإضافة 
الخاصية '2” إلى منتجنا القديمء حينها يمكننا إطالة عمر ذلك 
المنتج» وتقليل مجموعة الخصائص الأولية في المنتج الجديد 
وعرضهما معاً إلى أن يتم إصدار المجموعة الثانية من الخصائص» 
حينها يمكن تغييب المنتج القديم من السوق). ليس من المهم إنشاء 
وثيقة رسمية ضخمة. خصوصاً إذا كان هناك قاعدة متطلبات كافية. 
ولكن» من المهم أن يكون هناك أساس منطقي للقرارات (فضلاً عن 
البدائل)» إذ قد تكون هذه المعلومات الأساسية مفيدة في وقت 
لاحق. وعادة ما يتم فقدها. 
17 
إعداد خط المشروع 


إعداد خطةٌ إصدار الخسائص الخصائص الوظليفية ل 


خط إمذار الخصدائص 
لل تُحطليل المسار الحرج 


إعداد خطة البرمجة 


خطة المشروع 


إْ 


الشكل 5-7: مخطط عمل لمرحلة التطوير 
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سيعمل مصممو الهيكلية على تحديد المفاهيم الهيكلية التي 
ستقود الأنشطة» وسيعملون على تحليل أولي لوظائف النظام بشكل 
مستقل عن إنشاء خطة إصدار خصائص النظام. يتم عمل تقدير أوّلي 
للجهود بالاعتماد على التحليل الوظيفى (كما ورد فى الفصل الثامن). 
بعد أن نشم كن الأعقار امداق العيدل سم تسكن تتد وراك 
التكاليف والجهد أهداف زمن تهيئة المنتجات لتكون متاحة للبيع 
شك امناست: 


2-5-7 التخطيط خلال مرحلة التطوير 


خلال مرحلة التطويرء تصبح المتطلبات والبناء أكثر استقراراً 
بشكل تدريجيء ما يتيح للمهام أن تكون أكثر تفصيلاء والتقديرات 
أكثر دقة» ويتيح تفكيك الإصدارات إلى إصدارات هندسية أصغرء 
وليصبح الجدول منقّحاً بشكل أكبر. عادة ما يتم التخطيط بشكل 
مستمر خلال تنفيذ المشروع. خلال مرحلة التطوير» يتم تخطيط 
المراحل الأولى بالتفصيل» وما يتبعها من مراحل يتم تخطيطها 
تدريجياً بشكل أقل تفصيلاً. وبتقدم المشروع» يمكن تعديل الخطط 
وتخطيط مزيد من المراحل بثقة أكبر. يوضح الشكل 5-7 لمحة عن 
أنشطة تخطيط المشروع خلال مرحلة التطوير. 


3-5-7 التخطيط فى أثناء مرحلة التنفيذ 
يستمر التخطيط أثناء مرحلة التنفيذ. عند نهاية كل مرحلة» 
سيكون هناك تقويم نهائي للإطلاع على المواضيع التي سبق اختبارها 
خلال المرحلة الماضية» والإطلاع أيضاً على التقدم الذي تم إحرازه. 
وستكون النتيجة تعديل في المهام أو في العملية. 
ومن ثم سيكون هناك جلسة تخطيط تفصيلية للمرحلة التالية. 
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إضافة إلى ذلك» يقوم فريق التخطيط بتنقيح الخطة للمراحل القادمة 
خلال تنفيذ المرحلة نفسها. ويتم إجراء أهم التعديلات خلال ذلك 
بالتعديلات البسيطة. يلخص الشكل 6-7 لمحة عن أنشطة تخطيط 


إنجاز فريق العمل الفعلي 


إتداد خطة المشروع 


خطة المشروع المعدلة 


1 
الشكل 6-7: مخطط عمل لمرحلة التنفيذ 


6-7 الملخص والاستنتاجات 

قدمنا في هذا الفصل بعض التوجيهات المتعلقة بتخطيط 
الإصدارات. ولأننا نستخدم منهج الفترات البرمجية التكرارية» يتم 
معدل عبية المراصيه ال مراكن شتمر وا ضكيرة حيت ين يكور 
خصائص المنتج شيئاً فشيئاً مع مرور الوقت. بالإضافة إلى البرمجة» 
يتم تخطيط طرح مجموعات الخصائص في نسخ للسوق. أما المهمة 
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الرئيسة فهي تعريف الحد الأذنى من الخصائص التي يجب أن 
يحتويها المنتج ليكون جاهزاً للطرح الأول في مواقع العملاء. كما 
يجب أن يشمل التخطيط على مدة وجود المنتجات القديمة مع 
المنتجات الجديدة» ومتى وكيف سيتم تغييبها من السوق. 


7-7 أسئلة للمناقشة 
1. كم يجب أن يكون مقدار الجهد الأقصى الذي يبذله كل فرد 
من أفراد الفريق؟ 
2 كم يجب أن يكون الفارق الزمني المناسب بين الإصدارات 
الهندسية؟ 
3. ما أهمية تحليل المسار الحرج لتخطيط البريحة؟ 
4. كيف يختلف تخطيط المشروع من مرحلة إلى أخرى؟ 


المراجع 


ئءك1200. 
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الفصل الثان 


تقدير تكلفة المشروع 


دخل مدير بيل إلى مكتبه بعد ظهر أحد أيام الصيف وفي يده 
علبة من الصوداء وقال لبيل إِنْه يريد تقدير ميزانية تكلفة المشروع 
للسنة المالية القادمة بحلول يوم الاثنين. وأضاف: «وبما إنك ستكون 
قد بلغت مرحلة التنفيذ في ذلك الوقتء أريدك أن تزودني أيضا 
بعدد موظفي البرمجة ومتطلبات المكتب وأي تكاليف متعلقة برخص 
تطوير البرسحاك 1 ووقيا كان يدت ديه هاتفه النقال. فلوح لبيل 
بسرعة وخرج. 

وبينما كان مدير بيل يسير في الرواق» بدأ بيل بالتساؤل عن 
كيفية تحديد ميزانية تكلفة المشروع لمرحلة التنفيذ. فقد قام بعمل 
تخمينات لمشاريع من قبل» ولكن كان ذلك باستخدام موظفيه وفي 
موقعه. أما بالنسبة إلى مشروع تطوير البرمجيات الموزع هذا فسيحتاج 
إلى تخمين المصادر اللازمة في مواقع برمجة بعيدة» بالإضافة إلى 
طاقم العمل المحلي. كما إن عليه تخصيص وتوزيع الأعمال بين 
موقعه والمواقع البعيدة الأخرى. وهو لا يعرف شخصياً فريق العمل 
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في المواقع البعيدة» وليس لديه أدنى فكرة عن طريقة عملهم 
وكفاءاتهم. 

خلال مراحل البدء والإعداد. كان لدى بيل فريق عمل صغير 
نتدييا .كين هنك سي المتطلبات ومهندسي تصميم البواضط ات معن 
يعملون لديه. أما بالنسبة إلى مرحلة التنفيذ» فسيكون بيل مسؤولا عن 
فريق عمل أكبر بكثير من المبرمجين الموزعين في عدة مناطق 
جغرافية. وحسب احتياجات زمن تهيئة المنتجات لتكون متاحة للبيع» 
فكر بيل أن جزءاً كبيراً من عملية البرمجة سيتم بشكل موازء وبالتالي 
سيكون هناك حاجة إلى فريق عمل تطوير كبير نسبياً. وسيكون من 
الضروري الحصول على هؤلاء المطورين الذين سيحتاجون إلى مكان 
ليعملوا فيه وإلى تدريب وأدوات. ولمّا كان بيل يمعن التفكير في كل 
هذه الأمورء» شعر أن الحرارة ارتفعت قليلا في مكتبه الدافئ عمًا 
كانت عليه. 


خطة إصدار الخصائص 


ز! 


5 


الهيكليه 


تقدير الثكائيف 


زْ 


الشكل 1-8: مخطط عمل لتقدير التكاليف 
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نصف في هذا الفصل منهج تقدير برمجة نماذج البرمجيات في 
مشروع موزع في عدة مناطق جغرافية» وطريقة التحقق من التخمين 
الأصلي باستخدام تقنية التخمين من الأسفل إلى الأعلى» وعملية 
تقدير الجهود للمراحل الشهرية. كما إننا سنناقش تنفيذ وتنقيح 
التخمينات خلال مراحل المشروع المختلفة. انظر الشكل 1-8» وهو 
ملخص عن الأنشطة المتضمنة في تقدير المشروع. 


1-8 منهج التقدير من الأعلى إلى الأسفل 

يقوم التحليل الوظيفي للهيكلية (الفصل الخامس من هذا 
الكتاب) بتحديد الوحدات الوظيفية للهيكلية التي ستنقّذها فرق 
اللوميعة الموزعة اجحوافيا, عيدتك يكن .عمل تقزر لتكلنة النرسحة 
لمرحلة التنفيذ عن طريق تقدير الجهود للوحدات النمطية التي ينبغي 
برجقها نخلدل النعرات النؤفنط» النكرارئة الوط رواضانة الصنادر 
اللازمة لوظائف الفريق المركزي (أي» الهيكلية ومهندسي المتطلبات 
والاختبار وإدارة المشروع). وينبغي إدراك أن مثل هذا التقدير يتم 
خلال مرحلتى البدء والإعداد. وعادة ما تكون دقة التقدير فى مرحلة 
احفر 180 بالقئة 'وتكسي تعره 310 رالينة نكال ترساة التطون: 
أما المدخل الأولي لعملية التقدير فهو حجم تقدير كل وحدة عمل 
مخصصة, كما يقررها فريق مصممي البرامج. 


1-1-8 من هم المضطلعون بهذا النشاط؟ 
يكون مدير المنتج مسؤولاً عن نشاط التقدير» ولكن يكون لأعضاء 
الفريق الآخرين دورٌ فيه أيضاً . حيث يقوم مهندسو تصميم البرمجيات 
بتوفير مدخل لتقدير الحجم» ويمكن أن يشارك مهندسو المتطلبات في 
التحقق من أن تفاصيل خصائص النظام مأخوذة بعين الاعتبار. يوضح 
الجدول 1-8 ملخصاً عن المشاركين الرئيسين وأدوارهم. 
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جدول 1-8 المشاركون في تقويم المشروع 


الوظيفة النسوولية 


مصمم الهيكلية يوفر التقديرات المتعلقة بالحجم للوحدات. 
مهندس المتطلبات2 يقوم مهندس المتطلبات بالتأكد من تحقيق 
الخصائص المحددة (بمستوى متقدم فقط). 
2-1-8 ما هى المدخلات والمخرجات؟ 
تتضمن المتطلبات المسبقة اللازمة لتقديرات التطوير (تكون هذه 
التقديرات خلال مرحلة التحضير عبارة عن تخمينات فى الأغلب) 
تحديد الوحدات التي سيتم برمجتها وبعض تقديرات الحجم لهذه 
الوحدات. وكلما زادت كمية البيانات القديمة المتوفرة» وزادت ثقة 
مهندسي التصميم في تقديرات الحجمء تزيد دقة تقديرات التكلفة 
والجهود. وفي حال لم تتم معايرة البيانات القديمة للمشاريع الموزّعة 
في عدة مواقع. يتم وضع جهود إضافية في الحسبان بالاعتماد على 
التكلفة الإضافية للتعاون في مواقع التطوير الموزّعة جغرافياً. ويعتمد 
مدى تأثير هذا التوزيع في المشاريع في خصائص المشروع والشركة. 
يمكن الاسترشاد بمدخلات أنشطة تحليل المخاطر فى هذه 
التقديرات. وبحكم خبرتناء وجدنا أن التوزيع عموماً يفرض عامل 
جهد أكثر ب 1,2 إلى 2,5 مرة من عامل جهد المشاريع المنظمة. 


تكون مخرجات هذا النشاط على النحو الآتي: 
© تقدير الجهود المطلوبة من حيث جهود فريق العمل والتوقيت 


معا. 
© عدد فرق البرمجة وحجمها. 


166 


© جهود وحجم أنشطة الفريق المركزي (أي إعداد الهيكلية 
وهندسة المتطلبات والتكامل والاختبار وإدارة المشروع). 
تعتمد إجراءات هذه المخرجات على احتياجات الشركة؛ كما 


3-1-8 توكيد تطوير البرمجيات المورّعة المراكز 
لاحظنا أن مهندسي البرمجيات الذين يعملون في فرق برمجة 
صغيرة نسبياً هم أكثر إنتاجية من المهندسين الذين يعملون في الفرق 
كبيرة الحجم. وهذا نتيجة حجم التواصل المطرد المطلوب بين 
أعضاء فريق العمل في الفرق الكبيرة» ما يؤدي إلى مشاكل التزامن 
المعرفي (أي» عدم تطابق الفهم المشترك) المذكورة لاحقاً في 
الفصل الثالث عشر من هذا الكتاب. 
تم إيجاز توكيد تطوير البرمجيات الموزّعة المراكز في النقاط 
أدناه : 
© إذا كان حجم وحدات العمل صغيراً بحيث يمكن احتواؤها 
ضمن إطار عمل الهيكلية وتم تخطيط متطلباتها» فيمكن حينئذ 
توزيع البرمجة على عدة فرق حول العالم. 
© سيكون من المحتم وجود إدارة مركزية لدعم الهيكلية ونموذج 
متطلبات الأعمال ذات المستوى المتقدم» ودمج النظام 
والمصادقة عليه» ووضع خطة المشروع». وتصميم واجهة 
المستخدم رفيعة المستوى. وضمان الجودة» وبريحة الوحدات 
المشتركة المهمة . 
© إذا تم الإبقاء على حجم فريق بريجة الوحدات صغير نسبياً (مثلاً 
عشرة أشخاص أو أقل)» يمكن تطبيق عمليات سريعة لزيادة 
الإنتاجية وخفض وقت البريحة. 
من الناحية العملية» ما يعنيه التوكيد هو أننا نقوم بوضع قيود 
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على المصممين ليقوموا بتصميم هيكلية تكون فيها وحدات إسناد 
الأعمال صغيرة نسبياً؛ أي إنه يمكن برمجتها من خلال استثمار جهد 
عشرة موظفين في العام (أي عشرة أشخاص في اثني عشر شهرا). 
وهكذا يكون الهيكل التنظيمي الناتج عبارة عن فرق برمجة صغيرة 
موزّعة جغرافياً يتم التنسيق بينها من خلال فريق مركزي. تكون الفرق 
الموزّعة صغيرة بما فيه الكفاية بحيث يسمح بتواصل جيد بين أعضاء 
الفريق الواحد يومياً. علاوة على ذلك» يتم تصميم الهيكلية بحيث 
يكون هناك أدنى حاجة للتواصل بين الفرق (مثلا الهيكليات 
المتباعدة). يتم إسناد الأعمال للفرق الموزّعة بحيث يتم التواصل 
داخل الفريق ضمن موقع البرمجة أو مع الموقع المركزي فقطء ويتم 
الحد من التواصل بين فرق برمجة الوحدات في المواقع المختلفة. 

من الممكن مراقبة الآثر السلبي لحجم فرق تطوير البرمجيات 
المتزايد عن طريق القيام بتحليل «ماذا لو» باستخدام أدوات تقدير 
التكاليف. 

وبينما يزداد حجم شيفرة البرمجة المقدّرة لمشروع برمجة 
النظام» يزيد الوقت وعدد الموظفين اللازمين لإنجاز النظام. فإذا ما 
قام أحدهم بزيادة الجدول الزمني المقترح باستخدام أدوات تقدير 
التكاليف هذهء ينخفض الجهد وتكلفة البرمجة الناتجة إلى جانب 
حجم فريق الذروة. مع هذاء يكون هناك ضغط عمل لطرح المنتج 
فى السوق بالسرعة الممكنة. 
١‏ كذلك فإنه من الأرجح تغيّر المتطلبات والتقنيات خلال 
المشاريع طويلة الأمد. وبالتالي يكون حجم فريق البرمجة أكبر من 
الحجم المثالي (من منظور الإنتاجية)» وتكون الفرق الكبيرة أقل 
إنتاجية بسبب الاحتياج المتزايد للتواصل ما بينها. لذا فإن قاعدتنا 
الأساسية هي أن لا يزيد حجم أي فريق على عشرة أشخاصء وأن 
لا يحوي أي موقع برمجة ما يزيد على مئة مهندس (أو عشر فرق 
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تتكون كل منها من عشرة أشخاص). يكون الحد الأقصى لحجم 
الفريق اعتباطياً نوعاً ماء ولكنه يسعى إلى أن يتمكن من وضع فريق 
برمجة الوحدات بالكامل في غرفة اجتماعات واحدة. والوضع المثالي 
هو أن يتمكن فريق برمجة الوحدات بالكامل من العمل على بعد ما 
يقارب عشرة أمتار من بعضه بعضاً. 


يمكننا توضيح هذه المفاهيم باستخدام أدوات تقدير التكاليف. 
تأمل مخرجات أدوات التقدير لمشروع يتكون من خمسين ألف سطر 


من شيفرة البرمجة”*؟ 111008 كما هى موضحة فى الشكل 2-8. 
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يتطلب خفض جدول البرمجة ‏ لنقل من اثني عشر شهراً إلى 
عشرة أشهر ‏ استثماراً برمجياً أكثر بمرتين تقريباً. هذه المنحنيات غير 
خطية أبداًء وتفسّر على أنها آثار سلبية المهمة الناتجة من تواصل 
الفرق كبيرة الحجم. وكمثال على أثر حجم فريق البرمجة 
والوحدات» يمكننا طرح السؤال التالي: لتطوير نظام برمجيات يقدذر 
أن يتكون من 10012 من النقاط الوظيفية ووجود ثمانمئة مبرمج» فهل 
من الأفضل تنظيم مئة فريق يتكون كل منها من ثمانية أشخاص أو 
فريقين» يتكون كل منهما من أربعمئة شخص؟ 

إذا أدخلنا عدد 116 من النقاط الوظيفية إلى نموذج تقدير 
التكاليف لواحد من المئة فريق» المكون كل فريق من ثمانية 
أشخاص و50 من النقاط الوظيفية إلى أحد الفريقين المكوّن من 
أربعمئة شخص حصل على التقديرات الموجزة في الجدول 2-8. 

الجدول 2-8: أمثلة على تقديرات إكمال المشروع 

مئة فريق في كل منها فريقان في كل منها أربعمئة 
ثمانية أشخاص شخص 
جهد (موظف ‏ شهر) 64 7118 
جدول (شهر) 119 50,1 
فريق الذروة 7 340 

بمقارنة هذين الهيكلين التنظيميين يتبيّن» من هذا المثال» أن 
الفرق المئة الصغيرة يمكنها تطوير المنتجات خلال نصف الوقت 
والجهد الذي سيحتاجه الفريقان الكبيران. أما الأمر الجدير بالملاحظة 
فهو الجدول الزمني» إذ تتطلب الفرق الكبيرة ما يقارب خمس 
سنوات للبرمجة ماو ا للفرق الأصغر. لا يأخذ هذا 
المثال بعين الاعتبار أنه ينبغي دمج وحدات إسناد الأعمال المئة التي 


0ظ1 


طورتها الفرق الصغيرة أكثر مما يتطلبه الأمر لدمج الوحدتين اللتين 
طورتهما الفرق الأكبر. نهدف من خلال هذه المناقشة تأكيد الاتجاه 
بدلاً من التركيز على الأرقام الفعلية؛ إذ ندرك أنه بالإمكان المجادلة 
في صحة الأرقام المذكورة أعلاه» ولكن الاتجاه يعكس بدقة أن 
الفرق الصغيرة هى أكثر فائدة من الفرق الكبيرة. هناك طريقة مختلفة 
لكر لل ينات 35 الال وى رصي :فى «الجة ول 338 


الجدول 3-8: حجم التعليمات البرمجية مقابل الجهد 


20 الجهد (5241) الجدول 
الزمني (أشهر) 
10 3 5,5 
20 9 71 
30 24 8,6 
40 46 101 
50 56 106 
60 85 118 
10 117 12,0 


فريق الذروة 


0,9 
20 
3,8 
6,3 
75 

10,3 
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بازدياد حجم الشيفرة البرمجية المقدرة التي سيتم برمجتهاء 
يزداد الجهد بصورة غير خطية. وبالنسبة إلى مثال الشركة هذه 
خاصةء» تمت معايرة نموذج التقدير لبيانات المشروع السابقة» بما في 
ذلك العوامل المتعلقة بخبرة فريق العمل ومهاراته وبيئته. والتزاماً 
بقاعدة العشرة أشخاص والاثني عشر شهراًء يمكننا أن نطلب من 


ألف سطر شيفرة بر مجية. 
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4-1-8 الحجم 

تقوم كافة أدوات تقدير التكاليف باستخدام الحجم المقذر 
للمنتج الذي سيتم برمجته كمدخل أساسي. ولسوء الحظء يمكن أن 
تكون تقديرات التكاليف التي تنتجها أدوات تقدير التكاليف غير 
جيدة» وذلك لأن مدخلات تقدير الحجم نفسها قد لا تكون جيدة. 
من الصعب جدا على المصمم تقدير حجم وحدة البرمجيات قبل 
برمجتها. وقد تمت مناقشة مختلف المناهج والوحدات لتقدير الحجم 
فى كتب قياسات البرمجيات (2002 ,تاؤتانحهة2 :1993 ,طكتاجتوط 0ه 
10 . ونحن لسنا بصدد المشاركة فى هذا النقاش هناء ولكننا 
نقترح قيام مهندس التصميم باختيار الم الأكثر ملاءمة له. أما 
بالنسبة إلى المشاريع التي تخضع للدراسة والمذكورة في الفصول 
الأخيرة من هذا الكتاب» فقد قدمت معظم تقديرات باستخدام عدد 
أسطر الشيفرة البرمجية» وتم ذلك عن طريق عد أسطر الشيفرة 
البرمجية في مشاريع برمجة سابقة والتي كانت لها وحدات مماثلة 
للمنتج الجديد قيد التقدير. وهكذاء تكون الخبرة مهمة حين تقدير 
أحجام الوحدات الجديدة التي سيتم برمجتها. 

5-1-8 الجهد 

تقدم أدوات تقدير التكاليف مخرجات معلومات فريق العمل 
حيث يكون الجهد صغيراً في بداية المشروع» ويرتفع إلى الذروة عند 
نهاية البرمجة» ومن ثم ينخفض مرة أخرى عند وصول المنتج إلى 
مرحلة الصيانة. 

يتم حساب الجهد تحت منحنى ملف معلومات فريق العمل. 
نحن نقترح استخدام منهج برمجة تكراري ومتزامن حيث يتم برمجة 
الوحدات بشكل متواز لتحقيق أفضل زمن لتهيئة المنتج ليكون متاحاً 
للبيع. ويتم تصميم الهيكلية للحد من روابط الوحدات والمحافظة 
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على صغر حجمها. نتيجة لعملية البرمجة يمكن البقاء على صغر 
حجم فرق برمجة الوحدات والحد من حاجتها للتواصل والتواصل 
عبر المواقع المختلفة. 


ونتيجة الطبيعة التكرارية والمتزامنة لمنهجنا في البرمجة». 
واستخدام المراحل اللرمعة اعق تلوق عاية البرسنة جهرياء 
خرصي وراك نتروا يرميج الوعداسادني المدره ة البرمجية التكرارية. 
بل نوصي بتوفر فريق كامل في بداية فترة البرمجة التكرارية ويبقى معا 
بحجم ثابت طوال الفترة التكرارية. من الممكن إضافة فرق أخرى أو 
تعديل حجم الفرق للفترة التكرارية القادمة. ويمكن لمنهجية تعيين 
الموظفين السهلة هذه زيادة الجهد الكلي» ولكنها تهدف إلى خفض 
زمن تهيئة المنتجات لتكون متاحة للبيع وذلك لتحسين زمن تهيئة 
الفريق والتواصل والكفاءة ضمن فريق برمجة الوحدات. كما إننا 
نسعى إلى ثبات تعيين فرق البرمجة. وذلك لغايات تراكم الخبرات 
في المجال عبر الزمن. وهذا يخدم هدفنا بأن تصبح فرق برمجة 
الوحدات البعيدة بمرور الزمن أكثر شبها «بمراكز الاختصاص» التي 
تتمكن من المحافظة على الوحدات وتعزيزها للفريق المركزي» بدلاً 
من أن تكون مجرد «مناضد عمل ممتدة). 


ستختلف تقديرات الجهود بشكل كبير اعتماداً على من سيقوم 
بعملية التقدير. ويعود السبب في هذا إلى التنوع الكبير في إنتاجية 
وخبرة فريق عمل مهندسي البرمجيات. قفي حال قام شخص ما 
بمهمة مماثلة فى الماضىء. ستكون احتمالية قيامه بالمهمة الجديدة 
أسهل بكثير من شخص آخر لم يقم بهذه المهمة من قبل. وينبغي أن 
يقوم 0 0 سبؤدون العيل 0 مفدلة تقدير الجهرة 
أبعي أن لا يعرف الك المتش روم بداهة مستوى خبرة 
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أعضاء فريق العمل البعيد الذي سيقوم ببرمجة الوحدات. وهكذا 
ستكون هناك حاجة لنماذج التقديرء ولكن واقع البرمجة سيكون 
مختلفا اعتمادا على من سيقوم بالبرمجة. ستتم مناقشة منظور مشاركة 
الفرق البعيدة في عملية التقدير لاحقاً. 


6-1-8 الحدول الزمنى 

في بيئة العمل اليوم» يعتبر زمن تهيئة المنتجات لتكون متاحة 
تطوير البرمجيات عادةً إلى وقت لتطور ونضج النواحي التقنية. مثالياً 
يرغب مهندس البرمجيات في أن يتمكن من التفكير في منهجه الفني 
قبل تطبيقه» وأن يكون لديه الكثير من الوقت للاختبار وإعادة العمل 
حتى تتحقق جودة المنتج ؛ وهذا يتعارض مع حاجات العمل لطرح 
المنتج بسرعة؛ وبالتالي يشعر الكثير من مهندسي البرمجيات 
بالضغط» إذ إن عليهم تحقيق الجودة العالية ضمن قيود زمنية ضيقة. 
أما أسوأ سيناريو فهو حين يتم عمل هذا المشروع ضمن جدول زمني 
غير واقعي» مع إدراك الجميع لذلك» ويبدأ هذا الجدول الزمنى 
بالانهيار. هذا السبب الذي يدعونا للتشديد على الوفاء بكافة مواعيد 
مراحل المشروع وتقسيم المشروع إلى فترات تكرارية مع تواريخ 
مراحل شهرية ثابتة حيث يكون هناك إثبات على وجود تقدم في كل 
شهر. وبتقليص الفترات الزمنية بين مراحل المشروع» يمكن التركيز 
بشكل أكبر على المشروعء وإذا اقتضت الحاجة» يمكن إعادة 
التخطيط على نحو أكثر تواتراً. 


7-1-8 خطوات التقدير من الأعلى إلى الأسفل 
لمساعدة بيل في حل مشكلته المتمثلة في تقدير ميزانية التطوير 
لمرحلة التنفيذ» سنقوم بوصف منهج تقدير في ثماني خطوات: 
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تحديد أداة تقدير التكاليف. اختر أداة تقدير التكاليف (انظر 
البند 3-8) وقم بتحديده لشركتك. ويتم هذا بالنظر إلى 
مشاريع بريجة سابقة وتعديل المعايير أو خصائص التحكم 
بتكاليف النموذج (2000 ,[.1ة .أع] سستطعهظ :1981 مصطعه8) 
حتى تكون التقديرات المتحصلة من أداة التقدير مقاربة 
لتكاليف ما قبل البرمجة الفعلية. قم بعمل جدول مشابه 
للجدول 3-8 باستخدام أداة تقدير التكاليف المحددة. 

تقدير أحجام الوحدات. جلب تقديرات الأحجام من فريق 
الهيكلية لكل وحدة برمجيات محددة ضمن الهيكلية. سنستخدم 
مصطلح (وحدة البرمجيات» بحرية هنا لتعني وحدة إسناد 
الأعمال التي سيطبقها فريق البرمجة البعيد كجزء من الشيفرة 
البرمجية الوظيفية التي سوف تدخل ضمن نطاق عمل الهيكلية 
الذي قام فريق تصميم البريجيات بتعريفه. ضع قيوداً على فريق 
مهندسي التصميم حتى لا يكون هناك أكثر من مئة وحمسين 
وحدة ضمن التصميم » ولا تقدّر أي وحدة بأكثر من مئة ألف 
سطر من الشيفرة البريحية (أو ستين 121,005 للشركة المحددة 
في جدول 3-8). بمساعدة هذه القيود» سيطبّق هذا المنهج 
فقط على أنظمة البريجحيات المقدرة بخمسة عشر مليون سطر 
من الشيفرة البرمجية (811:005) أو أقل. بالإمكان وضع قيود 
على مهندسي التصميم ليقوموا بتحديد وحدات أقل من مئة 
ألف سطر من الشيفرة البريجية» وبالاعتماد على بيئة البريجة. 
إن القيد الأول هو تحديد الوحدات التي سيتم إسنادها إلى 
الفرق البعيدة التي يمكن أن يبريجها عشرة أشخاص ضمن 
فترة بريجة تكرارية مدتها أقل من سنة. وفي حال قام مهندسو 
التصميم بتقدير وحدة أكبر من القيود المفروضة على الحجم. 
ينبغي عليهم إعادة تصنيعها إلى وحدات أصغر. 

إسناد الوحدات إلى الفترات البرمجية التكرارية. ينبغى العمل 
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عن قرب مع فريق الهيكلية و«خبير الهيكلية» لفهم التسلسل 
الذي ينبغى برمجة الوحدات بناءً عليه. ستحتاج الوحدات 
الأكبر إلى وقت برمجة أطول. وقد قمنا بشرح مناهج تخطيط 
الفترات البرمجية التكرارية في البند 2-7. إذا التزم مصممو 
الهيكلية بقيود الحجم التي تم تزويدهم بهاء لن يزيد الزمن 
التكراري للفترة الواحدة عن سنة واحدة. 

تقدير حجم الشيفرة البرمجية لكل فترة برمجية تكرارية. إضافة 
أحجام كافة الوحدات المسندة لكل فترة برمجية تكرارية. ومن 
ثم حساب متوسط حجم الوحدة لكل فترة برمجية تكرارية. 
ينبغي الأخذ بعين الاعتبار أنه يتم استخدام تقديرات الحجم 
الفعلية لكل وحدة حين وضع خطة البريجة. ويعتبر استخدام 
متوسط الحجم لكل فترة برمجية تكرارية في هذه المرحلة أسهل 
لتحديد تكلفة البرمجة المقدرة لمرحلة التنفيذ بسرعة. 

تقدير زمن البرمجة والجهد وفريق الذروة لكل فترة برمجية 
تكرارية. استخدام متوسط حجم الوحدة لكل فترة برمجية 
تكرارية» حساب زمن البرمجة والجهد وحجم فريق العمل 
باستخدام أداة تقدير التكاليف المحددة أو من الجدول الذي تم 
وضعه في خطوة 1 (انظر مثال الحدول 3-8). 

لكل فترة برمجية تكرارية يتم تقدير زمن البريجة ومتوسط 
حجم فريق العمل» وضبط زمن البريجة إلى أقرب عدد من 
الأشهر ومتوسط حجم فريق العمل لأقرب عدد فريق ذروة. 
تقدير زمن جدول البرمجة. حساب زمن جدول البرمجة عن 
طريق إضافة أوقات البريجة لكل فترة برمجية تكرارية» ومن ثم 
إضافة زمن اختبار التحقق فى النهاية بالاعتماد على الخبرة 
المتكونة من المشاريع السابقة (مثلاً: من شهرين إلى ستة 
أشهر). يمكن اعتبار زمن اختبار التحقق في النهاية مرحلة 
ثشات. 
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8. تقدير تكلفة البرجة. حساب جهد التطوير موظف ‏ شهر عن 
طرق حر مرك لوعو دريو ف الجر الور لكر اي 
بعدد الوحدات مضافا إليه جهد المتطلبات المركزية والهيكلية 
وإدارة المشروع وفرق الاختبار. يتم حساب تقدير تكلفة 
البرمجة عن طريق ضرب إجمالي عدد الأفراد في سنوات 
المشروع بمتوسط تكلفة فريق العمل في السنة للشركة. والناتج 
سيكون عبارة عن التكلفة إذا قامت الشركة بالبريجة في 
موقعها. أما إذا رغبت الشركة في برمجة الوحدات في 
الخارج» فستستخدم تكلفة متوسط فريق العمل في سنوات 
المشروع لكل شركة مزودة لحساب تكلفة البرمجة» والتي 
ستكون أقل من التكلفة في موقع الشركة. 
أثناء إعداد خطة البرمجة» يؤخذ بعين الاعتبار السيناريوهات 
المختلفة للبرمجة ومقارنة التكاليف ذات الصلة بالاعتماد على عدد 
الفترات البرمجية التكرارية والمزودين المختارين وحجم الفريق 
المركزي وغير ذلك. ويتم إنشاء ملف ذي مستوى متقدم عن 
معلومات الموظفين وجدول البرمجة الزمني الى يمكن :تراجعبه مج 
الإدارة قبل الالتزام بخطة البرمجة. يبين الشكل 3-8 مثالا على 
معلومات فريق العمل. 

كمثال قصير على كيفية تقدير تكاليف مرحلة التنفيذ باستخدام 
الخطوات الثماني المذكورة أعلاه» لنفترض أن لدينا عشرين وحدة 
تحتاج إلى برمجة» وقمنا بتقسيم العمل على موقعين خارجيين. 
لنفترض أيضاً أننا قسمنا مشروع البرمجة إلى فترتين تكراريتين تتكون 
كل منهما من عشر وحدات سيتم برمجتها بواسطة خمس فرق عمل 
في الموقعين أ و ب. إن حجم الشيفرة البرمجية المقدر للفترتين 
البرمجيتين التكراريتين الأولى والثانية هو ثلاثمئة ألف سطر وخمسمئة 
ألف سطر على التوالي. وهكذا يكون متوسط حجم الوحدة ثلاثين 
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ألف سطر من الشيفرة البرمجية للفترة البرمجية التكرارية الأولى 
وخمسين آلف سطر من الشيفرة البرمجية للفترة البرمجية التكرارية 
الثانية. بالاستعانة بالجدول 3-8 يمكن تخطيط الفترة التكرارية الأولى 
لمدة تسعة أشهر بمتوسط حجم فريق عمل مكوّن من أربعة 
مهندسين. أما الفترة التكرارية الثانية فسيتم تخطيطها لمدة أحدّ عشر 
شهراً بمتوسط حجم فريق عمل مكوّن من ثمانية مهندسين. 1 

وهكذاء ستتطلب الفترة التكرارية الأولى ثلاثمئة وستين موظفا 
فى عدد الأشهر (ثلاثين موظف فى السنة) لفرق العمل العشرء أما 
الفترة القوارية لكان يمطلت كمائمنة وكمائين .موقا تت عند ا لاشقاد 
(73,3 موظف في السنة). ويتم تقدير ذلك خلال 000 التنفيذ. 
وسيكون هناك حاجة لمصممَّيْنء ومهندسيّن أو ثلاثة مهندسي 
متطلبات من مدققي البرمجيات» ومديرَيٌ تزويدء إضافة إليك بحكم 
عملك في موقعك المركزي» وسيكون مجموع ذلك مئتي موظف في 
أشهر المشروع (16,7 موظف في السنة). وإذا كان تقدير تكلفة 
الموظف الواحد لمدة سنة في الموقع مئة وخمسين ألف دولارء وفي 
الموقع مئة ألف دولار» وفي الموقع 'ب” ثمانين ألف دولار» 
فسيكون تقدير التكلفة فى مرحلة التنفيذ حوالى 2,5 مليون دولار 
لموقعك». و5,2 مليون وولاو في الموقة 3 و 4,1 مليون دولار في 
الموقع "ب0. وبتقدير تكلفة إجمالية تصل إلى اثني عشر مليون 
دولار. عند العمل على خطة البرمجة» سيكون هناك حاجة للنظر فى 
شنو لفو يناد الرسحزات تخالل لقو فى البرمتعقي انكر روي ولك 
يمكنك أن تخبر مديرك الآن أن عليه أن يطلب موازنة تصل إلى اثني 
عشر مليون دولار لأعمال البرمجة خلال عشرين شهرأ من بداية 
مرحلة التنفيذ. في الواقع» ربما ينبغي عليك أن تطلب حوالى اثنين 
وعشرين مليون دولارء لأن مثل هذا التقدير الأولى يشكل 80 بالمئة 
من الهدف المطلوب. 1 
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2-8 التقديرات من الأسفل إلى الأعلى 
عند تحديد فرق البرمجة المرشحة للعمل». من الحكمة إتاحة 
الفرصة أمامهم لتقديم تقديرات مستقلة لبرمجة الوحدات. يقوم الفريق 
المركزي» في محاولة لتحديد الفترات البرمجية التكرارية للإصدار 
التزايدي» بتقدير من الأعلى إلى الأسفل لوحدة متوسطة الحجم لكل 
فترة برمجية تكرارية. وسيتم تزويد فرق البرمجة بعدد كامل من 
الموظفين المتفرّغين من بداية فترة البرمجة التكرارية إلى نهايتها. هذه 
العملية مفيدة كخطوة تحقق من التقديرات الأصلية» حتى يكون هناك 
صدقية لفريق البرمجة وحتى تكون ملكية التقدير تابعة له. ولغاية البدء 
في إسناد مهام البرمجة للوحدات الجديدة من قبل الفريق المركزي» 
يتم منح فرق برمجة وحدات التطبيق ما يأتي : 
© جزءاً من المتطلبات المتكاملة ونموذج التصميم ليتم تطبيقها. لقد 
تم وصف هذا النموذج باستخدام لغة النمذجة الموحدة (انظر 
الفصل الثالث من هذا الكتاب). وقد تم إبلاغ فرق البرمجة 
البعيدة بخصائص التطبيقات بواسطة حالات الاستخدام. 
© وصفاً لهيكلية البرمجيات. يتم وصف الهيكلية باستخدام وثيقة 
وصف الهيكلية أو نموذج التصميم (انظر الفصل الخامس من 
هذا الكتاب). 
© اختبارات القبول. وهي اختبارات القبول التي ينبغي اجتيازها 
لقبول الوحدة التي تم برمجتها. 
© خطة البرمجة التكرارية وتواريخ الدمج. يتم تزويد مخطط جدول 
زمني محوري يحدد مدة الفترة البرمجية التكرارية والتواريخ 
الثابتة للتكرارات التي سيتم إصدارها للدمج المركزي وفريق 
الاختبار. 
© مواصفات واجهة الوحدة. تحدد هذه المواصفات كيفية ربط 
الوحدة التي سيتم برمجتها بإطار عمل الهيكلية. 
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#تطو ار النموذج الرأسي. هذا تطبيق خفيف للنموذج للحد 
الأدنى للتشغيل عبر كافة طبقات الهيكلية المستخدمة كمثال 
على فرق برمحجة الوحدات. 


© دليل أسلوب واجهة المستخدم (1[1). الذي يحدد تصميم مظهر 
واجهة المستخدم الذي سيتم استخدامه. 


فور تسليم حزمة وثائق التكليف لموقع العمل البعيد» يتم منح 
فريق البرمجة في ذلك الموقع مهلة مدتها أسبوع للرد عن طريق 
تقديم تقدير من الأسفل إلى الأعلى لجهود برمجة الوحدات المحددة 
وفق جدول البرمجة التكراري المحدد. وتشير الخبرة المكتسبة من 
المشاريع السابقة إلى قاعدة مهمة مفادها أن هناك حاجة إلى أربع 
ساعات من كل فرد لتقدير جهد الوحدة من الأسفل إلى الأعلى. فلو 
قام كل عضو في فريق برمجة الوحدات بعمل تقدير وكان حجم 
الفيق حاشور) بكر البخاطوو. خيكها يكن تطيق الأر يعن بناغة 
على تقدير من الأسفل إلى الأعلى لكل وحدة خلال مهلة الأسبوع 
الممنوحة للرد. 


من المقترح أن يقوم الفريق المركزي بقبول تقديرات برمجة 
الوحدات من دون طرح أي أسئلة تكون ضمن نطاق أكبر بمرتين من 
تقدير من الأعلى إلى الأسفل الذي تقوم وسيلة التقدير بتقديمه (انظر 
الجدول 3-8). كما ينبغي التشكيك في التقديرات التي تكون أقل بكثير 
أو أعلى بكثير من ضعفي التقدير من الأعلى إلى الأسفل. وينبغي 
مراجعة التقديرات للوحدات التى تحتوي على درجة مخاطرة عالية من 
المحتمل تعديلها. كما يقترح تزويد كل فريق برمجة بحجم فريق ثابت 
لكافة مدة الزيادة. يمكن طبعاً الاستعانة ببعض الموظفين الرئيسين لكل 
الجودة ومديري المشروع) في موقع برمجة محدد. 
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فكرة مفيدة: 

لا تقم بإعطاء وعود لإدارتك بعمل توفير كبير في 
تكاليف البرمجة من خلال القيام بالأعمال في الخارج. 
فعلى الرغم من أن أسعار العمالة بالساعة يمكن أن تكون 
أقل بالنسبة إلى المواقع الخارجية مقارنة بالموقع 
المركزي» غير أن محدودية الخبرة في المجال والحاجة 
إلى التواصل الإضافي قد تعوض أي توفير في التكاليف. 
على سْبيل الشفال» عيدها تكرن تكله السالة (بالسافة) 
في المواقع البعيدة ثلث مثيلتها في المواقع المحلية» 
تحتاج الفرق البعيدة إلى إعادة التطبيقات مرتين إضافيتين 
للحصول على تشغيل صحيح للمنتج. لذا لن يكون هناك 
توفير فى تكلفة البرمجة. وقد لاحظنا أن الفرق البعيدة قد 
تحتاج دن ركه اشير إلى اتعى: طشتر هرا اقول مطارقة 
إنتاجية الموقع المركزي عند عملهم في مجال عمل 


جديد أو تكنولوجيا جديدة. 


على الرغم من أن نسب تكلفة موظف ما في السنة قد تكون فعلياً 
أقل في المواقع الخارجية مقارنةً بالموقع المركزي» غير أن تكلفة 
التواصل الزائدة المصاحبة للعمل في مواقع متعددة ستعوض أي توفير 
في تكاليف البرمجة؛ وسيحتاج مديرو التزويد في الموقع المركزي 
للعمل مع الفرق البعيدة» وستزيد موازنات السفرء كما سيكون هناك 
حاجة لإعادة العمل بسبب الخلل في التواصل. كما ينبغى الأخذ بعين 
الاعتبار أنه سيتم الاستعانة ا لبرمجة ب كبيرة من 
الشيفرة البرمجية» ولكن يمكن أن تمثّل جهود وضع الشيفرة البرمجية 
ما نسبته 20 بالمئة من مجمل تكلفة برمجة المنتج. إضافة إلى ذلك» 
يمكن أن تكون تكاليف الصيانة المصاحبة للمنتج الناجح مساوية أو قد 
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تتجاوز تكاليف البرمجة. كما يمكن أن تكون التكاليف المصاحبة 
لعملية إطلاق منتج جديد في السوق مساوية أو قد تتجاوز تكاليف 
البرمجة» كأن يتم تدريب موظفي المبيعات. ومع هذاء وعلى الرغم 
من أن أسعار العمالة في الساعة لبعض الدول قد يثير اهتمام إدارة 
الشركة؛ لا بد من الحرص حين أخذها بعين الاعتبار في مجمل 
تكاليك بزمخة الحمع وإصداره وصائتة: ْ 


موأةلزاولا 3.ععما 2م 1 عم معأدع0 مقام 


14 69 69 69 20 4 1منومععة ا" 
14 28 54 69 20 4 2وزرومعع؟5 "ا 


الشكل 3-8: مثال على معلومات الحاجة لموظفين 
في مراحل المشروع المختلفة 


3-8 أدوات التقدير 
لقد بدأ استخدام أدوات تقدير تكاليف البرمجيات منذ أن بدأ 


مديرو العمل في طلب تقديرات عن تكاليف برمجة وتطوير المنتجات 
البرمجية الجديدة. هناك كتاب يتحدث عن مسألة تقدير تكاليف 
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البرمجيات وهو «اقتصاديات هندسة البرمجيات» لمؤلفه بويهم. يصف 
المؤلف في هذا الكتاب الذي نشر عام 1981 نموذج تكلفة البناء أو 
ما يعرف بنموذج (0)0000210*". كما تم نشر كتاب تقدير تكاليف 
البرمجيات بواسطة 11 0م006 عام 2000. وبالإضافة إلى نموذج 
0 +» تعتمد أدوات تقدير تكاليف البرمجيات شائعة الاستخدام 
على تحليل 5111316 و211085 وتحليل النقاط الوظيفية (224) 
:2002 ,طقتاته2 :1991 رؤ5عمهل :1983 ,لإاعمقه0 ل0صهة غطءءىرط[ه) 

.(1992 ,للتقمابط 


يمكن أن يتراوح سعر أداة تقدير تكاليف البرمجيات من لا شيء 
(حيث يمكن لأي شخص أن يعثر على وسيلة حساب بسيطة 
بالاعتماد على 00001410 في موقع عام على شبكة الإنترنت)» إلى 
آلاف الدولارات (حيث يتم جمع الأداة في عمل استشاري لقياس 
البرمجيات. إذ يتم تحليل المشاريع السابقة والمستقبلية بالاعتماد 
على بيانات البيئة والإنتاجية للشركات الحالية). يأتى العديد من 
الأدوات مكلت بنياناك كاري دمن لهات اديع لضن 
القطاعات الخاصة. وفي حال لم يكن لدى الشركة بيانات تاريخية 
جيدة من برمجة منتجات سابقة» فبالإمكان مطابقة المنتج بمنتجات 
مشابهة وتحديد الأداة بالاعتماد على بيانات القطاع. ويقوم العديد من 
مديري مشاريع البرمجيات في وقتنا الراهن بتحميل أداة تقدير 
التكاليف على حواسيبهم النقالة حتى يتمكنوا من عمل تحليل ماذا 
لو) أثناء ترحالهم. 

من الواضح أن الأشكال والرسوم البيانية والجداول التي تنتجها 
أدوات تقدير التكاليف تثير إعجاب الإدارة غير التقنية. ولكن غالبا ما 


(:) 51001 005:6 عكتاع نا ماوم 00 - 0000110 
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تحتوي هذه الأشكال الجميلة على تقديرات غير دقيقة للغاية عندما 
تكون مدخلات الحجم غير دقيقة أو عندما لا يتم تحديد الأداة 
بشكل صحيح. ومع ذلك» تعتبر هذه الأدوات جيدة لمساعدة مديري 
البرمجة على تذكر كافة الأجزاء التي تدخل في تقدير التكاليف وتقدم 
لهم إطار عمل زمني كلي (على سبيل المثال» «لا يمكن برمجة هذا 
المنتج في غضون ثلاثة أشهر؛ أو إذا أمكن ذلك فستكون هذه أول 
مرة في تاريخ شركتنا"»). علاوة على ذلك» يمكن أن يقوم مديرو 
المشروع باستخدام أداة التقدير والجدول من الأسفل إلى الأعلى 
لتثقيف الإدارة ووضع توقعات مناسبة حتى يتم أخذ الجداول وحجم 
الفريق والمخاطر بواقعية في عين الاعتبار قبل البدء في التطوير واسع 
النطاق في مواقع البرمجة الخارجية. 


4-8 الملخص والاستنتاجات 

يعتمد منهج تخطيط المشروع والتقويم المذكور في هذا الفصل 
على التأكيد على أنه يمكن برمجة الكثير من منتجات البرمجيات من 
خلال فرق برمجة موزرّعة في عدة مناطق حول العالم في حال تمت 
صياغة المتطلبات وقام مصمم الهيكلية بتقسيم وظائف النظام إلى 
وحدات صغيرة يمكن تطبيقها تدريجيا. 

ويعتمد هذا على الملاحظة التي مفادها أن مشاريع تطوير 
البرمجيات الأصغر تكون أسهل في الإدارة وتكون فرق البرمجة 
الأصغر أكثر إنتاجية. إضافة إلى ذلك» يعمل العديد من عمليات 
تطوير البرمجيات السريعة بشكل أفضل عندما تكون الفرق مكوّنة من 
عشرة أشخاص أو أقل. مع هذاء يقوم منهجنا في تخطيط المشاريع 
الموزعة باستخدام فريق مركزي لإدارة مجموعات فرق البرمجة 
الصغيرة التي يشارك كل منها في برمجة وحدة برمجيات تندرج ضمن 
بناء تصميم البرمجيات. 
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يمكن تطبيق منهج تقسيم النظام المعقد إلى عدد من الوحدات 
الصغيرة ضمن تخصصات هندسية أخرى. على سبيل المثال» تم 
تقسيم تصميم طائرة بوينغ 777 إلى 240 نظاماً فرعياً. 

وقد تم تعيين ما يقارب عشرة الاف موظف في عملية التطوير» 
ولكن عملت فرق عمل أصغر بكثير على تطوير كل نظام فرعي 
(1997 ده عماعظ لصة طاندم5). إن تقسيم المهمة الكبيرة إلى عدد 
من المهام الصغيرة ضروري لتصميم وتخطيط وهيكلة وتنظيم وتقويم 


5-8 أسئلة للمناقشة 
1. كيف يمكن تقدير أي توفير ممكن في تكاليف البرمجة المرتبطة 
بالمواقع الخارجية؟ 
والإنتاجية؟ 
3. ماهو الزمن اللازم لتعليم فريق عمل يعمل عن بُعد ليصبح 
وفيا قن عال عمل عدي 
4 ما هي الكلفة التي يتم إنفاقها على المهام المتعلقة بالبرمجة 


المراجع 


ئك1200ك/ 


0 101177 12511111011011 0051 توسروى .21.1 أع] .117 لاتتو8 ,مستاعمظ 
.00 ,11211 عع معط :1.7 رمع 9ن 520016 تعمم تلآ .ممقتل8 17 .11 


43 م مة .مام تكتل8 15 .كع 11ره دمع ج171 1ع©171ج 171 انط وى . 
1 للة1آ-عع امعط :.ل .الخ ,لان 


-ل0 210 ج11 للاكى لم :711711 الاكهء أل :50/101 0 1اصمك .15عم03) روعصول 
,انآ -اكونناعء لطا اده ا علا .مراف [ه01) تنه مراةم1ا 
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:كع 11171 507/10 .طانتانه .ل أعتصددآ لطه لاعتتساع لط -1 نما ,معلاءه346 
 171121:012 0 127001121 106121021116111. 9‏ 10 011102 5 :0111101161 "مر 
ورووع21 إأع501 عنام دده00 181815 :لخن ,وه ]وام 


-© 07102 1/1[ أعء[0 21 نا 0ك 06711116 -© 476771161107 .ل اأعلمددآ ,انتانوط 
2 بلزعاوء 015020-177لمى :نذالا :مادم .7116711 

©1001 50 عأطوذاء1 :عءترءاأءع عط م[ د لاوه 11 .11 عمماء 3171[ ,لتقمالط 
2 ,1311] ععتخطعءط اه لا بن اك .1ع للا 11171 آظا ,1717116 011 

ص11أمه12671 .تعد 1عمصاع ]1 .0 1202210 له .0 ماوع بطاتختصردى 


مام عآ1ه لا بعال .كلم0 1 مس78 ,دعاسلا مس11 :177 ©1176 لأس8ط 1 
.7 ,5025 ع /زع11/الا 


1000 


1 50157/316>)» الإعماكلد0 .18 صطول لصهة .ل متذللث ,خلاءءتطام 

كذ :2011002 8110116 اتمعمطمه1ء7ع10 له ,عل00 01 وعطاآ عع نامك 

١7211010.« 1111 117071506110115 07 50/1017 ©‏ ععمعككهد عخله 5018 
.639-6458 .مم ,1983 ,6 .20 ,9 .1701 :1712 1112171661 
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فرق تطوير البرمجيات 


قام بول في مشروعه الأخير بقيادة مجموعة صغيرة من 
المبرمجين وفاحصي البرمجيات ممن لهم قدرة على العمل معاً 
كفريق. وكان قد تم تعيين عدد قليل من أعضاء الفريق حديثا من 
الخريجين الجدد. وبعد أن أنجزوا أول إصدار برمجى لأحد العملاء» 
كان العديد من أعضاء الفريق قد أصبحوا أصدقاءء إضافةً إلى كونهم 
زملاء. وعلى الرغم من أنه كان عليهم العمل لساعات إضافية أحيانا 
لتسليم العمل حسب الجداول الزمنية المحددة» غير أنهم كانوا 
بلنقون عند العجل لصوو ساراة قن 'لحية النسول ميف أن البو 
شتاءً. استمتع بول بالعمل مع هذا القروق: واستمتع رارف 
التي كانوا يرسلونها لبعضهم عبر البريد الإلكتروني إلى جانب آداء 
عمله في مراجعة وقراءة الشيفرة البرمجية التي كانوا يكتبونها. 

كان متوقعاً أن يقوم بول في مشروعه الجديد بإدارة مجموعة من 
فرق البرمجة» وقد كان بعضها موجوداً على مسافات بعيدة عن موقع 
عملهء وتحديداً في الهند وسلوفاكيا والبرازيل. ولم يقم بتوظيف أو 
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حتى مقابلة أي من هؤلاء المهندسين البعيدين. بل كان كل ما يعرفه 
عنهم الأجر الذي سوف يتقاضونه من الشركة عن كل ساعة عمل» 
وقد كان متحمسا لوقف التعيينات فى مكان العمل وجعل جزء كبير 
من متتجاث عمل البرمجة يهم .في 'الخارجء' كان بول قلقاً من الآلية 
التى يمكن بها إنشاء وإدارة ومراقبة هذه الفرق الخارجية. كما إنه 
فكك ف إمكانة مشاركته فى أى نشاط فى رياضة البيسبول أو 
الهوكي مع أعضاء هذه الفرق الجديدة. ْ 

نوضح في هذا الفصل الهيكل التنظيمي لفرق البرمجة الموزّعة 
في عدة مواقع وتحديد قواعد العمل وتحديد المسؤوليات وطرق 
التواصل والتواصل بين الفرق والتنسيق بينهاء وكيفية معالجة أمور 
المراقبة والتحكم. كما يوضح هذا الفصل بعض آليات العمل 
المستخدمة لتتبع التطور في المشاريع التي تعمل فيها مثل هذه الفرق. 
1-9 هيكلية مشاريع تطوير البرمجيات المورّعة المراكز 

كما ذكرنا سابقاً» أصبح التنسيق والتحكم والمراقبة أكثر صعوبة 
بسبب المسافات الشاسعة التي تفصل فرق برمجة التطبيقات بعضها 
عن بعض. نحن بصدد تقليل الحاجة المفرطة للتواصل عن طريق 
تحسين التعاون بين المجموعات ما أمكن وذلك عن طريق تقسيم 
هيكلية النظام البرمجي إلى أنظمة ووحدات أصغر حجماً وأقل ترابطاً. 
عندئذ يمكن أن يعمل كل فريق على الأنظمة الجزيئية والوحدات 
بشكل منفصل نسبياً عن الفرق الأخرى. يتم تعريف الوحدات بناءً 
على الخصائص التي يجب تنفيذها للمنتج وكذلك هيكلية النظام 
البرمجي كما وصفه المصمم. 

لتحقيق هذا الهدف. يتم تعيين فريق صغير من المصممين 
كجزء من التنظيم المركزي مع وجود أعضاء يعملون دواماً كاملاً في 
الموقعين الداخلي والخارجي. ويعمل الفريق كجزء من مشروعء 
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ويوجد مدير إنتاج مسؤول عن دورة حياة المنتج كاملة. يقوم مهندسو 
المتطلبات الموجودون في الموقع المركزي بتحديد وتحليل 
الخصائص التي يتطلبها أصحاب المشروع. 

تُلخص في الفصل الثامن الأعمال التي يسلمها الفريق المركزي 
إلى فرق البرمجة التي تعمل عن بُعد لتمكينهم من وضع الخطط 
وتقدير الجهد الذي يجب بذله لبرمجة الوحدات المطلوبة. يتم إنشاء 
هذه الأعمال خلال مراحل المشروع المبكرة عندما يكون الفريق 
المركزي صغيراً ومنتظماً في موقع واحد. نوصي بشدة أن تلقى مهام 
الفريق المركزي على عاتق بعض أعضاء فرق البرمجة الذين تم 
تعينيم سكل موده في لفرت الور حرق رص فليم اللعكل عن 
بُعد لاحقا. يُستغل الوقت الذي يقضونه في الموقع المركزي (على 
ستة أشهر مثلاً) «لتدريبهم» في مجال التطبيق والهيكلية والأدوات 
والعمليات التي ستُستخدم أثناء عملية البرمجة. يؤمل أن يصبح هؤلاء 
الأعضاء قياديين لفرق البرمجة التي تعمل عن بُعد حين عودتهم إلى 
مواقعهم الأصلية؛ إذ سيبدأون العمل مع مديري التزويد» الذين هم 
موظفون في الموقع المركزي يساعدون في إدارة العلاقات والمشاريع 
مع مواقع العمل عن بُعد أو مع مزودي الوحدات التي سيتم برمجتها. 
لذاء وبشكل عام» تكون النقطة الفاصلة في العملية بين الفريق 
المركزي المنتظم وفرق البرمجة التي تعمل عن بُعد هي اللحظة التي 
كم فيه إضدان' التصميم التفصيلي: سوف يبقئ 'الغريق. المركري 
يجقييا خلال عور قمليات الرفحة لكل قد وجوه عفن أعضاء 
الفريق إلى مواقعهم الأصلية. 

خفت حدة بعض مخاوف بول في ما يتعلق بالعمل مع مصادر 
غير معروفة بفضل انتقال الأعضاء بين الموقع المركزي وموقع 
التزويد. وقد لا يعرف بول الجميع في مواقع البرمجة التي تعمل عن 
بعد لكن لا بد أنه قد اكتسب خبرة على مدى ستة أشهر عمل 
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أثناءها مع بعض الأشخاص الأساسيين في الموقع البعيد والذين قد 
عملوا معه في الموقع المركزي. نعتقد أن هذا النوع من التواصل 
الشخصي ضروري لدعم التواصل مع مواقع العمل البعيدة خلال 
عملية البرمجة. وقد يكون من المهم بشكل خاص معرفة الزملاء في 
موقع التزويد بشكل شخصي وعميق حين حدوث أي مشكلة في 
المشروع. ويكون حل المشاكل عن بُعد صعباً إذا لم يكن أعضاء 
المواقع المركزية والبعيدة قد التقوا أو عملوا مع بعضهم بعضاً. 


الشكل 1-9: مثال على تنظيم الهيكلة التنظيمية لعملة البرمجة المورّعة 
المراكز 


وكما ورد في الفصل الثاني» يقوم الفريق المركزي المنتظم 
بتعديل فريق عمل المشروع خلال مرحلتي البدء والتطوير. حالما تبدأ 
مرحلة التنفيذ» يتم إضافة فرق البرمجة التي تعمل عن بُعد إلى 
المترابطة. يتخذ التنظيم الكلي للمشروع الهيئة الموضحة في الشكل 
1-9» إذ يعمل الأعضاء الموجودون جميعهم في المواقع المختلفة 


تسعمق وظائف: القريق المركرى :الى يق تتظرينها أولا يذل 
مرحلتي البدء والتطوير وحتى الوصول إلى مرحلة التنفيذ. يقوم الفريق 
المركزي بقيادة الفرق التي تعمل عن بُعد ومراقبة عملها. يقوم الفريق 
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المركزي بإنجاز التصميم المتعلق بالمفاهيم وهندسة المتطلبات» يتم 
تصميم وبرمجة الوحدات بواسطة الفرق التي تعمل عن بُعد) ومن ثم 
يتم دمج واختبار المنتج ضمن فترات برمجية تكرارية طالما تقوم فرق 
البرمجة عن بُعد بتسليم الشيفرة البرمجية إلى الفريق المركزي. 
لذلك. يكون الفريق المركزي هو مركز السيطرة والتواصل والذي 
تحججل, تطوور البرمهياتك الموزعة المزراكر أموا ممكنا 'سصييدن 
الوظائف التي يؤديها الفريق المركزي ما يأتي : 


© هندسة المتطلبات. تحليل المتطلبات التى يطلبها العملاء أصحاب 
المشروع. وتوزيع خصائص النظام إلى إصدارات ووحدات. 
تطوير نموذج المتطلبات. وتوفير الخبرات في مجال العمل 
المطلوب في فرق البرمجة. 

© تصميم هيكلية البرمجية. تصميم ووصف الهيكلية من حيث 
المفاهيم. إنشاء التصاميم ذات المستويات المتقدمة (يمكن ذلك 
بمساعدة الفرق التي تعمل عن بُعد). مراجعة ومراقبة 
التصاميم حين تطبيقها. كما يمكن أن يطوّر فريق تصميم 
هيكلية التطبيقات نماذج لاختبار هيكلية التبادل وتحديد 
الجدوى التقنية منها. وقد يتم إحضار هذه النماذج من الموقع 
المركزي أو من المواقع التي تعمل عن بُعد. هذا وسوف يحدد 
المصممون التقنيات والأدوات والإجراءات التي سيتم 
استخدامها فى البريجة. 

©» وضع خطة المشروع. وضع التقديرات. إعداد الجدول الزمني 
والموازنات والإجراءات. واختيار مواقع البريجة التي تعمل عن 
بُعد وتحديد مهامها. وتحديد الأهداف الفورية. 

© تصميم واجهة المستخدم. تصميم دليل لنمط واجهة المستخدم. 
وتطبيق تحليل الاستخدام والاختبار. وإعداد نموذج لمخطط 
سير واجهة المستخدم. 
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© تكامل النظام والتحقق من صحته. إعداد خطة للإنتاج. وإعداد 
نموذج اختبارات قبول الوحدات. وإعداد اختبارات النظام 
وإجراء الاختبار خلال عملية البرمجة التدريجية. 
© ضمان الحودة. تحديد عمليات الحودة والاختبارات. والمساعدة 
في تحليل مخاطر المشروع. ومراجعة عمليات وانجازات موقع 
التزويد. والمساعدة في تحديد عمليات المراجعة. المساعدة في 
تطوير عمليات البرمجة. 
يتم نقل حزمة التوثيق من الفريق المركزي إلى جميع فرق 
برمجة الوحدات التى تعمل عن بعد كما وّصف فى الفصل الثامن. 
يتم استخدام حزمة التوثيق هذه للمساعدة في نقل العطل الذي سيتم 
إنجازه إلى فرق البرمجة التي تعمل عن بُعد وفقاً لخطة البرمجة. ويتم 
تحديد نطاق العمل المطلوب تنفيذه من قبل فريق برمجة يعمل عن 
بُعد صغير الحجم نسبياً (عشرة أفراد كحد أقصى). يتم وصف 
وظائف أعضاء هذه الفرق لاحقاً. لكن وبشكل عامء لا بد أن يمتلك 
هؤلاء الأعضاء مهارات متعددة بما في ذلك مجال العمل والتصميم 
والبرمجة والاختبار. إضافة إلى ذلك» سيتم ربط فرق البرمجة التي 
تحعبل عن مداع الترين الم عرقي من لان مدي الدرويله يكل 
أساسي وأيضاً مع وظائف الفريق المركزي التي تم ذكرها سابقا 
كتصميم التطبيقات وتكامل النظام واختباره. في الواقع» سيتم تشكيل 
مجموعة مركزية لكل وحدة بحيث تعمل الفرق البعيدة بخبرات 
متعددة من الفريق المركزي. فعلى سبيل المثال» إذا كان فريق 
البرمجة (4) الموجود في الهند يعمل لإنجاز إطار عمل وحدة واجهة 
تطبيق المستخدم» قد يعمل في مجموعتهم المركزية كل من بيل 
الذي وضع المواصفات الوظيفية للوحدة» وجورج من فريق 
التصميم» وآرون من فريق تصميم واجهة المستخدم» ودان مدير 
التزويدء وغيرهم. 
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بناء على ما سبق» سيتكون التنظيم الكلي للمشروع من فرق 
برمجة تعمل عن بُعد تتناسب مع الهيكل التنظيمي للشركة المحلية 
التي تقوم بإرسال تقارير إلى الفريق المركزي المكون من خبراء 
تقنيين» كما تم وصفه سابقاً. تزوّد الفرق التي تعمل عن بُعد الفريق 
المركزي بشيفرات البرمجة وأي أعمال أخرى لازمة» ويقوم الفريق 
المركزي باستخدامها لبناء المنتج. على كل حال» نوصي أن يتم 
إنشاء هذه العلاقة من المزود على المدى الطويل. لذلك» فمع مرور 
الوقت. سوف يقوم التنظيم الذي يعمل عن بُعد ببرمجة تطبيقات أكثر 
للتنظيم المركزي» ويصبح ذا علاقة بأنشطة المراحل الأولية بشكل 
مطرد. إضافة إلى ذلك» ولنجاح مثل هذه العلاقة بمرور الوقت» 
نوصي بتبادل أعضاء فرق العمل كمندوبين لفترات طويلة أو قصيرة 
بين الفرق التي تعمل عن بُعد والفريق المركزي. وسيعتمد نجاح أي 
توك وبقافة "تلك" الع عونا كلوقه شكطن: الصدوذا الرطيرة 
والجغراقلف ضاي اعدف للد الموجودة بين الزملاء والعلاقات بينهم. 
ويمكن أن تتطور هذه الثقة المتبادلة بين موظفى الشركة بتطور 
اللفاقل السحسن يفي قن الوضم السالى المسارساث حتت 
البرمجيات» نشك فى أن يكون أسلوب الاستعانة بالمصادر الخارجية 
المتبع اننا جيه يكم إويناك المواصفات إلى مواقع العمل عن 
بعدى ومن ثم انتظار وصول شيفرة البرمجة ,21.[1 اء] اعاوطم2) 
(2005. 


يوضح الشكل 2-9 مثالاً لشركة مبيناً فيه العلاقة بين الفرق 
المركزية والفرق التي تعمل عن بُعد. ويتحمل مدير المنتج المسؤولية 
الكاملة عن الفترة اللازمة لبرمجة المنتج. ويكون رئيس التصميم 
مسؤولاً عن أعضاء فريق التصميم ويتحمل المسؤولية عن أي قرارات 
تقنية قد تؤثر في المشروع. يقوم أعضاء الفرق التي تعمل عن بُعد في 
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يوجد في مواقعهم. وترسل الفرق التي تعمل عن بُعد التقارير إلى 
مدير المشروع في الموقع المركزي من خلال مدير التزويد المحدد 
لهم. تقوم المجموعة المركزية لكل وحدة بربط الاختصاصات 
الوظيفية المختلفة بين الموقع المركزي ومواقع العمل عن بُعد. 


المثال الموضح في الشكل 2-9 هو مثال على العلاقة بين 
الفريق المركزي وأحد المواقع التي تعمل عن بُعد. ويجب أن يتم 
تنظيم الوحدات والتطبيقات المتشابهة ما أمكن. ويتم تجميع الوحدات 
إلى تطبيقات أو أنظمة جزئية ويتم تكليف فرق البرمجة بها في موقع 
ويرتبط الهيكل التنظيمي عادةً في مواقع العمل عن بُعد مع الموقع 
المركزي. على كل حال» يكون التواصل بين عدة مواقع عمل بعيدة 
ضرورياً أحياناً» كأن يكون هناك وحدتان تتطلبان واجهة تطبيق 
مستخدم يقوم بإنشائها كلا الفريقين. من المفيد جدا أيضأ أن تتبادل 
المواقع الخبرات التدريبية المكتسبة. ويكون هذا مفيداً حين إحضار 
فرق جديدة أو استبدال فريق بآخر بحيث تتعلم هذه الفرق عن 
الأنظمة من الفرق الأخرى. وفي كل الأحوال» يجب أن يتم تكوين 
هذا الارتباط بحذر مع مرور الوقتء لأنه ربما ينظر كل فريق إلى 
القويق الآخربيشكل:تقافبين فى يداية الأمو إلى "أن تيده تكرين 
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2-9: العلاقة بين الفرق المركزية والفرق التي تعمل عن بُعد 


ال 


اللسي الت 


ام ام 


كدت انا 


فكرة مفيدة: 

يجب أن تقاوم أي اقتراحات قد تحوّل الفريق المركزي 
إلى توي و مخادل مرساتي البدةوالتطوين. 
لاحظنا أن بعض الأنشطة تتطلب تفاعلاً مستمراً ومتقارياً 
بين أعضاء الفريق كتحليل المتطلبات وتصميم الهيكلية. 
لذلك نؤكد أن مثل هذه الأنشطة يجب أن تكون منتظمة. 
نظراً إلى الحاجة إلى إحضار أعضاء جدد للفرق التي 
تعمل عن بُعد خلال المراخل الأولية للمشروع». ستطرأ 
أمور لوجستية. عندما يتم نقل أعضاء من فريق يعمل عن 
بعد ليعملوا فى موقعك». سوف تزداد التكلفة بسبب 
كاليف الستر والمعيضةة إن تسيو مرقم ملل أعضناء 
الفريق وابتعادهم عن عائلاتهم يؤدي إلى الشعور بالغربة 
أو قد يؤدي إلى رحلات عودة غير متوقعة. ويستطيع 
أعضاء الفرق التي تعمل عن بُعد العمل في الموقع 
المركزي برفقة عائلاتهم. وإذا لم يكن ذلك ممكناًء يتم 
التخطيط لرحلات منتظمة بحيث يعمل الفريق المركزي 
لعدة أسابيع» ومن ثم يعود الجميع إلى بيوتهم لمدة 
أسبوعين. على كل حالء» كان لنا تجارب سيئة عندما 
حاولنا في إدارة فريق مركزي لا يوجد في موقع واحد. 


1-1-9 الوظائف والمسؤوليات 
بينما يلخص الجدول 2-9 وظائف ومسؤوليات الفريق الذي يعمل 
عن بُعد. 
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الجدول 1-9: وظائف ومسؤوليات الفريق المركزي 


الوظيفة 


مدير المشروع 


مدير التزويد 


الخبير في مجال 
العمل 
المتطلبات 


مسؤول تطبيق 
العمليات (خبير 
في ضمان 
الجودة» 


مصمم واجهة 


المسؤولية 

يضع خططاً لدورة حياة المنتج» يقوم بإدارة فرق المتطلبات 
الموزّعة عالمياً. 

يضع خططاً لدورة حياة أحد عناصر المشروع» ويعمل على إدارة 
جد عخاصتو قرف التروبجة التي تال عن حدر 

إلى متطلبات» يطور نموذج التحليل وقائمة المصطلحات. يترجم 
النموذج التحليلى إلى مستندات تتضمن متطلبات العمل. 

يقوم بتعريف ووصف وربط هيكلية البرنامج. ويتخذ القرارات التقنية. 
المكوّنات. يطور المواصفات واحتبارات القبول لمكوّنات المنتج. 
يقوم بدعم العمليات والتدريب على مهام متنوعة. ويدعم الإدارة 
بالاستعانة بفريق هيكلية المشروع. وإدارة أخطاء النظام واختبارها. 
مسؤول عن دعم البرمجة وعمليات الاختبار وأدوات ضمان 
الجودة. مسؤول عن ضمان القدرة على تتبع نتائج المشروع. 


ربما كانت الوظيفتان الأكثر أهمية في أي مشروع برمجي هما 
مدير ا 2 لمنتج (أو مدير ا لمش وع للمشاريع | لكبير ( ومدير التصميم. 
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وقد تمَّثْ مناقشة الأدوار والعلاقات بين مدير المنتج ورئيس التصميم 
في (2002 طمتاتحة2 لصة 2000 ,[.21 اع] معاذاعصةه8) على التو الي . 
ويهتم رئيس التصميم بشكل أساسي بالأمور التقنية المتنوعة 
للمشروع» بينما يهتم رئيس المنتج بالأمور الإدارية المتعلقة بالمشروع 
كالإطار الزمني والموازنة والتنظيم وتشكيل فرق العمل ووضع العمل. 
في المشاريع البرمجية المورّعة» يجب أن يتخذ مدير المنتج ورئيس 
التصميم قرارات حول الفريق الموزع في عدة مناطق جغرافية والذي 
لا يعمل تحت إشرافهم المباشر. لذلك. وبالإضافة إلى المهارات 
الإدارية والتقنية الأساسية المعتادة» يجب أن يكون كل من مدير 
المنتج ورئيس التصميم قادرين على العمل مع أفراد فريق عمل مكوّن 
من عدة شركات ومن ثقافات متنوعة. ستتطور مهارات التواصل 
لديهم بما إنهم يقومون بقيادة فريق عمل لم يقابلوا أفراده من قبل 
ولديه دافع أدائي يختلف عن دافعهم. ونوصي بأن يكون لدى الفريق 
المكلف بهذه الوظائف خبرات ثقافية أو أن يُعطى دورات في هذا 
المجال في مرحلة مبكرة من المشروع. إضافة إلى ذلك» يجب أن 
يتمتعوا بالمرونة والقدرة على التكيف كلما تقدم المشروع وكان هناك 
تغيرات على الوضع العام خارجة عن إطار السيطرة» كالظروف 
السياسية في الدولة التي يوجد فيها فريق البرمجة المسؤولين عنه. 


الجدول 2-9: وظائف ومسؤوليات فريق برمجة الوحدات 


الوظيفة المسؤولية 

مدير البحث يقوم بوضع خطة دورة حياة الوحدة التي سيتم برمجتها ويعمل على 

والتطوير إدارة فرق المشروع. 

مصمم الهيكلية يعمل كعميل مفوّض يعمل على حل الأمور المتعلقة بمجال العمل 
أو الهيكلية» يِتَحَْذْ قرارات تقنية تتعلق بهيكلية الوحدة وتصميمها. 

المصمم يعمل على تصميم الوحدات باستخدام أنماط التصميم المناسبة. 
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المبرمج يطبق الوحدات ويتحقق من الشيفرة البرمجة ويعيد كتابتها إن لزم 
الأمر لضمان جودتها. 

خبيرضمان يختبر الوحدة كمجموعة واحدة حين برمجتها. 
الجودة 

يتم التحكم بالتواصل والتنسيق الكلي للمشروع عن طريق 
الفريق المركزي. يتم التحكم بالأنشطة التقنية عن طريق قادة الفرق 
التقنية الوظيفية. يتم التحكم بأنشطة المشروع عن طريق مدير المنتج 
يكون عبارة عن فترات برمجية تكرارية ومستمرة مكونة من مراحل 
شهرية. ويتم تحديد أهداف كل مرحلة زمنية مركزياً بالاعتماد على 
خطة البناء وخطة التكامل والدمج وخطة الاختبار. ونوصي بأن يتم 
التخطيط بشكل تفصيلي عن طريق كل فريق وحدة في كل مرحلة 
زمنية. يجب أن تكون مواعيد التسليم محددة» لكن قد يكون هناك 
نقل لبعض الخصائص من مرحلة زمنية إلى أخرى. هذا وتكون عملية 
وهو عضو في الفريق المركزي ويجب أن يكون على علم وافٍ 
بمخطط العمل. 


فكرة مفيدة: 

إحرص على مشاركة الجميع. 

من الصعب عادةً قياس مستوى المشاركة وفهم جميع 
الأعضاء للفريق الذي يعمل عن يُعد. غالباً ما يكون أحد 
الأشخاص متحدثاً باسم الفريق ما يعني اختصار الطريق 
أمام أعضاء الفريق الذي يعمل عن بُعد للوصول إلى 
الهدف عن طريق الفريق المركزي. ومن الوسائل المتبعة 
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للتغلب على ذلك أن يتم تحديد وظائف لجميع أعضاء 
الفريق (إضافة إلى كونهم مبرمجين): ويطلب منهم إعداد 
تقارير عن بعض حالات العملء» والإجابة عن أسئلة 
تتعلق بالوظائف الموكلة لهم. قد يساعد هذا في ضمان 
مشاركة جميع أعضاء الفريق وإتاحة الفرصة لاكتشاف أي 
أمور قد تطرأ مبكراً. 


2-9 الحجم 

اقترحنا في الشرح السابق أن لا يزيد عدد أفراد الفريق على 
عشرة أشخاص» وأن لا يكون في الموقع الواحد أكثر من عشر فرق. 
وقد استّنتجت هذه القاعدة عن طريق التجربة. تعرفنا على حالات 
تعدى فيها عدد الأشخاص في الموقع الواحد ثلاثمئة شخصء» وعلى 
الرغم من ذلك استمروا في العمل بنجاح؛ وقد بدأت جميع هذه 
المشاريع صغيرة. إن اعتماد أسلوب التوزيع الجغرافي في برمجة 
التطبيقات هو نموذج تغيير أساسي وتحتاج الشركة إلى وقت لتطبيقه. 
وما لا شك فيه أن الانتقال إلى مشروع برمجة موزع ضخم من دون 
خبرة سابقة أمر خطير. لذا نوصي مبدثياً أن يكون عدد المواقع في 
البداية موقعين أو ثلاثة مواقع بحيث لا يزيد عدد المبرمجين على مئة 
في جميع المواقع. في مرحلة الانتظام في العمل» لم يسبق أن رأينا 
أي مشروع ناجح» في عدد من المواقع» يزيد على سبعة أو ثمانية 
مواقع. 

إذا كان لديك مشروع يتعدى حجمه الحدود القصوى المقترحة 
التي تم ذكرها سابقاً. ننصحك باتباع أسلوب المناوبة في العمل 
لخفض العدد الكلي للفريق. ومن الاراء المقترحة زيادة البرنامج 
الزمني للبرمجة وتضمين مناوبات إضافية للأعضاء. كما ينصح رأي 
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آخر بأن يتم تقسيم النظام إلى أنظمة جزئية مختلفة بحيث تصبح 
مشاريع متعددة ومستقلة. وقد ساعد اعتماد أسلوب خطوط الإنتاج 


الكثير من المشاريع في تطبيق هذه الطريقة من التقسيم بشكل فعلي. 


فكرة مفيدة: 

تأكد من أنه يمكن استيعاب كل فريق فى غرفة واحدة. 
كمه ارآى اناق عن عر يجين الدسجت 1لا برا عد 
أفراد فريق مبرمجي الوحدات على عشرة مبرمجين؛ لو 
كان هذا الفريق يعقد اجتماعات يومية بشكل غير منتظمء 
سيكون هناك حاجة ملحة لمكان لعقد الاجتماعات. لذاء 
سوف يحتاج المشروع إلى قاعة مؤتمرات أو إلى غرف 
عمل خاصة لعقد الاجتماعات» وبالتالي سيكون حجم 
الفريق محدوداً بحجم الأماكن المخصصة المتوفرة. إذا 
لاحظت أن الفريق يجتمع في مكان واحد غير أن 
التواصل بين أعضائه غير منظم وغير مريح» يجب أن 
تعيد تنظيم الأمور في هذه الحالة. 


3-9 الملخص والاستنتاجات 

سوف يكون تنظيم مشروع التطبيقات المورّعة الخاص بك 
مختلفاً عن تنظيم المشروع الموجود بشكل كامل في مبنى واحد 
حيث تعمل. على الرغم من أنك ستتبع العديد من الممارسات 
الإدارية التي كانت مفيدة وتعمل بشكل جيدٍ في السابق» فإنه يجب 
أن تعمل على التعويض عن القدرة على التواصل الفعّال مع فرق 
البرمجة التي تعمل عن بُعد. إضافة إلى ذلك» سيصبح لديك قدرة 
أقل على السيطرة على المشروع وسوف تعمل مع فريق عمل لم 


تتعرف عليه وقد لا تقابله نهائياً. ستستعين بمديري التزويد لديك 
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كأعضاء فعّالِين لتقليص الهوّة بينك وبين الفرق التي تعمل عن بُعد 
فق نا كملق بالفواميان كه انلك متتشائظ تعلى فيمونة العلكقة حك 
وبين المزودين لأمد طويل لأنهم سيصبحون امتداداً أساسياً لشركتك 
مع مرور الوقت. 


4-9 أسئلة للمناقشة 

1. ماأهمية التعرف الشخصى على بعض الأعضاء المميزين فى 
الفريق الذي يعمل عن بُعد قبل الشروع في مرحلة إنشاء 
المشروع؟ 

2 كيف يمكنك إعداد تنظيم لمشروع موزع فعال بحيث يتعدى 
حدوة الشركة والدولة؟ 

3. ماهي الأدوار الوظيفية المهمة التي تقوم بأخذ القرارات التقنية 
والإدارية في المشروع؟ 

4. في أي مرحلة من مراحل المشروع تكون المجموعات المنتظمة 
ضرورية؟ 


المراجع 
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الفصل العاشر 


المدير المزود 


ؤُلدت آن في ولاية وسكنسون والتحقت بجامعة بيدرو» وتعمل 
الآن في شركة برمجيات كبيرة خارج مدينة شيكاغو. على الرغم من 
أنها قامت بزيارة العديد من الأماكن في الولايات المتحدة الأميركية 
وأوروبا أثناء رحلات العمل» وزارت مدينة ديزني الترفيهية مع العائلة 
فى العظلة» غير أنها لا تزال تعتير نفسها مواطنة متثمية إلى :قتمال 
الولايات المتحدة. 


تحرص الشركة التي تعمل فيها أن على خفض تكاليف 
المنتجات البرمجية عن طريق نقل بعض أعمالها إلى شركات خارجية 
في الهند ودول أوروبا الشرقية. وكنتيجة لعمل آن الناجح في إدارة 
مجموعة برمجة صغيرة» فكر مديرها في منحها وظيفة جديدة كمديرة 
تزويد. لم تفهم آن ما هي طبيعة وظيفة مدير التزويد»ء لكن مديرها 
حذرها من أن وظيفة مدير التزويد تنطلب السفر بشكل مستمر إلى 
مواقع الفرق التي تعمل عن بُعدء وأنها يجب أن تشد الرحال 
وتتحقق من تاريخ انتهاء جواز سفرها حالا. 
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نَصف في هذا الفصل الوظيفة المهمة المسؤولة عن إدارة مواقع 
البرمجة الخارجية. فإن مدير التزويد هو أحد أعضاء الفريق المركزي 
يقوم بإدارة ثمانية إلى عشرة مبرمجين تقريباً في مواقع البرمجة التي 
تعمل عن بُعد. وقد تم تطبيق نماذج تنظيمية مختلفة حول المكان 
الذي يجب أن يوجد فيه مدير التزويد ضمن تنظيم المشروع الموزع. 
وسوف نناقش الخصائص التى يجب أن تتوفر فى مدير التزويد الفعَال 
رقم لضع بعلي تدر عد عن يسول :ف تملها الرضافة: 


1-0 الوظائف والمسؤوليات 
كوكبيرن (2002 ,متتتاطاعءاء00)) : 
© البرمجة في مواقع مختلفة : يتم تنفيذها في عدد قليل نسبياً من المواقع 
مع وجود مجموعات كاملة من المبرمجين الذين يقومون ببرمجة 
الأنظمة الفرعية بوجود واجهة معرفة جيدة للنظام الفرعي. 
موقع واحد إلى المبريمجين في دولة أخرى. وتفتقر المواقع البعيدة 
© البريحة الموزّعة: لقبت مجازاً «البرمجة التى لا تغيب عنها 
ام ماه حو امار مد ار 
البرمجة ذات لي له الور مما 
وجود فروق فلسفية واقتصادية ونموذج بنية الفريق. 0 
لأي شخص في هذا النوع من البرمجة المساهمة بكتابة الشيفرة 
البرمجية» غير أن هناك حماية لقاعدة البريحة الأساسية. 
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في منهجنا من أجل تطوير البرمجيات الموزّعة المراكزء أرسلنا 
المواصفات إلى المواقع التي تعمل عن بُعد في البلاد الأخرى» لكن 
في نفس الوقت قمنا ببناء عناصر الخبرة في الفرق التي تعمل عن 
بُعد عن طريق مشاركتهم في أنشطة المراحل الأولية في الموقع 
المركزي. يساعد مدير التزويد في بناء هذه الخبرات عن طريق تكوين 
العلاقة بين الفريق المركزي والفريق الذي يعمل عن بُعد. 

فى شركة سيمنز» نعرّف البرمجة بالاستعانة بالمصادر الخارجية 
(512111001118 210 128أ011501110) على أنها القيام نمه وعم اجن أجز اء 
المنتج البرمجي خارج نطاق مبنى شركة البرمجة المحلية أو في أحد 
أقسام شركة سيمنز الأخرى. ويشير مصطلح البرمجة الاستعانة 
بالمصادر الخارجية عادةً إلى البرمجيات التي يتم تنفيذها خارج مبنى 
القركة فلن كز اله تلاك شرك سبيسه فروها كاملة أن جرقة 
في دول كالهند والبرازيل والصين وأوروبا الشرقية حيث تنفذ البرمجة 
بالاستعانة بالمصادر الخارجية. 
الإفصاح عن الإنجازات بحيث تكتب بطريقة مشتركة بين أعضاء 
الفريق والشركة الفكرية المملوكة من قبل الشركة الأم. ويتم إنجاز 
العمل عن طريق عقد داخلي بسيط يتم من خلاله تحديد الأهداف 
والمنجزات والتكاليف وطرق الدفع وسياسات تدرّج العقوبات 
وإجراءات فصل الموظفين عند الحاجة. ويتم الاتفاق على أسلوب 
الحوافز والخصومات لمكافأة أو معاقبة فريق يعمل عن بُعد على 
مكافات الشركة المزوّدة للعاملين عن بُعد جيدة لتحافظ وترفع 
التمويل من التنظيم المركزي بمرور الوقت. أما الوضع الأفضل فهو 
أن يتم تمويل الفريق الذي يعمل عن بُعد. صاحب الأداء الجيد 
بشكل متكرّر خلال سنوات مالية متعددة» ويتم استدعاء الفريق 
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للمشاركة في صيانة المنتج الذي قاموا ببرمجته والمشاركة في أعمال 
برمجية جديدة. لذلك» يقوم مدير التزويد بتسهيل نقل التقنية من 
الموقع المركزي إلى المواقع التي تعمل عن بُعد بحيث تصبح هذه 
المواقع منافِسَّة للموقع المركزي بمرور الوقت. ويعمل هذا النموذج 
بشكل فعَال في شركة سيمنز بافتراض أن العمل التجاري لديهم ينمو 
باستمرار. وأما إذا كان العمل التجاري متراجعاًء يتم التخلص من 
المواقع التي تعمل عن بُعد كإجراء أولي. 

تُعرّف عملية تطوير البرمجيات الموزّعة المراكز على أنها 
مشاركة فرق البرمجة المورّعة في عدة مواقع. وتكون هذه المشاركة 
مدير التزويد بمهارات القدرة على العمل والتواصل بفاعلية مع 
أخرى» وهى الرغبة فى السفر والتنقل والاستعداد له. 

هناك بعض المخاطر التي قد تثير قلقاً حول مشاريع تطوير 
البرمجيات المورّعة المراكز مقارنة بالمشاريع التي تتم في موقع واحد 
بحيث يساعد مدير التزويد فى العمليات الإدارية؛ وتتلخص هذه 
المخاطر في ما يأتي : 

© ضعف القدرة على التحكم بالجدول الزمني للعمل والتكاليف 

ومستوى أداء العمل. 

© احتمال وجود نقص فى الكفاءات الأساسية. 

© الوقت والمسافة. 

© عدم القدرة على فهم الثقافات» والتواصل» واللغة. 

© درجة التعقيد. 
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© السياسة. 
هناك ثمة مخاطر سياسية تحيط بالعمل الذي يتم ضمن أطر 
دولية ليس لها أثر في مشاريع التطوير التي تتم في موقع واحد. فقد 
يتمكن مدير التزويد من التعامل مع بعض هذه المخاطرء وقد يكون 
بعضها فوق حدود قدرته. وحين حدوث أي أحداث سياسية غير 
متوقعة» يؤدي مدير التزويد دوراً مهماً في نقل صورة عن المخاطر 
المحتملة إلى الفريق المركزي ويعمل على وضع خطط عمل بديلة. 
ومن الأمثلة على المخاطر السياسية : 
© العمالة : 
8# الدول الصناعية مقابل دول العالم الثالث: 
ا الموظفون مقابل الذين يعملون في خطوط الإنتاج. 
السلع الاستهلاكية مقابل التخصصية. 
8# مديرو تقنية المعلومات والمديرون الماليون والمديرون 
التنفيذيون مقابل المبريجين. 
الأعمال التجارية الكبيرة مقابل العمال. 
الأعمال الآلية مقابل الحرف اليدوية. 
© الحكومة : 
أسلحة الدمار الشامل. 


© الصناعة : 
ا الملكية الفكرية. 
ا ميزان القوى. 
8# العلاقة بين المنتجين والمزوّدين والبائعين. 
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أصبح التنسيق والتحكم أكثر صعوبة بسبب المسافات الكبيرة 
التي تفصل بين فرق العمل في مشاريع تطوير البرمجيات الموزّعة 
المراكز جغرافياً. وتتلخص وظيفة مدير التزويد في تقليص هذه 
المسافات عن طريق العمل كرابط بين التنظيم المركزي والتنظيم الذي 
يعمل عن بُعد. ويساعد العمل الذي يقوم الفريق المركزي بطلبه من 
فريق البرمجة الذي يعمل عن بُعد في تخطيط وتقدير الجهد اللازم 
لإنجاز الوحدات التي يقومون ببرمجتها إلى حد ما. على كل حال» 
سوف يساعد مدير التزويد - وهو موظف لدى الموقع المركزي - 
على إدارة العلاقات والمشاريع مع الفريق المركزي. 

إن التواصل الشخصي مع مدير التزويد أمر ضروري لدعم 
التواصل مع الفريق الذي يعمل عن بُعد خلال عملية البرمجة. ومن 
الواضح أن المعرفة السابقة الشخصية تكون ضروريّةَ عند حدوث أي 
عوائق في تنفيذ المشروع. إن إيجاد الحلول لمشاكل المواقع التي 
تعمل عن بُعد أمر صعب إذا لم يكن العاملون في الموقع المركزي 
والعاملون في الموقع الذي يعمل عن بُعد قد التقوا أو عملوا مع 
بعضهم من قبل. 

يمكن تلخيص مسؤوليات وظيفة مدير التزويد في مشاريع تطوير 
البرمجيات المختلفة كالآتي : 

إدارة الموارد (تقريباً من ثمانية إلى عشرة أفراد) والمشاريع في 
مواقع تطوير البرمجيات التي تعمل عن بُعدء وإدارة العلاقة بين 
المزود والتنظيم المركزي» وتسهيل التواصل بين الفريق المركزي 
والفريق الذي يعمل عن بعد. 


2-0 المهارات المطلوبة 


يمتلك مدير التزويد العديد من مهارات مدير المشروع البرمعجي 
ومهارات أخرى أيضاً. قمنا بنقل مهام ومهارات مدير مشروع 
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البرمجيات فى الجدول 1-10 من المصدر (2002 ,طوتلتتة2) . 


سيكون مدير التزويد بحاجة إلى العمل مع الأعضاء من كلا 
الفريقين المركزي والذي يعمل عن بُعد. لذلك» يجب أن تكون 
مهارات الاتصال والتواصل الثقافي التي يمتلكها أكثر كفاءة منها لدى 
مدير مشروع يقوم بإدارة موقع واحد فقط. ومن الأمثلة على المهارات 
التى يمكن استخدامها بشكل فعّال من قبل مدير التزويد مهارة التحدث 
سوالقات فشكن أشي كاذ السمل بابلعة لاجيي :دكن كن 
أن يستخدم مدير التزويد لغة الفريق الذي يعمل عن بُعد للتواصل 
الاجتماعي بشكل أفضل. إضافة إلى ذلك» من المفيد فهم ثقافة الدولة 
التي يعمل فيها الفريق الذي يعمل عن بُعد. 


كما إن امتلاك مدير التزويد درجة عالية من المرونة والقدرة 
على الحركة أمر مفيد للغاية. وعلى الأرجح سيقوم مدير التزويد 
برحلات طويلة ومتكررة إلى موقع الفريق الذي يعمل عن بُعد. ومن 
الأفضل أن يشعر مدير التزويد بأن مثل هذه الرحلات ممتعة» وليست 
مجرد روتين مُملُ. نشججّع مدير التزويد والأعضاء الآخرين الذين 
يعملون لدينا في مشروع التطوير الموزع للمشاركة في رحلات جوية 
وبرامج فندقية دائماً. إذ إنه لا تتم رحلات السفر في بعض الأحيان 
كما هو مخطط لهاء فلذا تساعد المرونة في تجنب المشقة المحتملة. 


في مشروع نظام إدارة المباني الآلي» لوحظ أنه عند ترتيب 
اجتماعات في دولة أجنبية حول المشروع» يتأخر بعض الأعضاء بسبب 
مواعيد رحلات الطيران؛ ما يجعل الاجتماع غير فعٌال ويعكر صفو 
الأجواء والأمزجة, ويُوَدَي إلى نفاد الصبر وغير ذلك من الآثار السلبية. 
ولهذا السبب» ننصح بتنظيم وظائف الفريق المركزي بحيث يكون مدير 
التزويد قادراً على التغلب على الصعوبات المتعلقة بالسفر والتنقل. 
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صنع القرارات 


ال ريسع 


الحدول 1-0: وظائف مدير المشروع 


الوصف 
يجب أن يكون مدير المشروع 
قادرا على عرض رؤية ناجحة 


يجب أن يمتلك مدير المشروع 
مهارة التوجيه؛. ويعمل كمراقب 
لأعضاء الفرق التى لا تمتلك 
السي و او اسار عدا 
الفرق التي تمتلك خبرة أكبر» 
ويقوم بالتطوير تبعاً لظروف 
العمل. 

يجب أن يأخذ مدير المشروع 
قرارات في أوقات معينة حول 
المشروع بحيث لا يعمل على 
وقف استمرارية عمل أعضاء 
الفريق. 

يجب أن يقوم مدير المشروع 
بتنسيق التواصل الضروري بين 
أعضاء الفريق» ويوفر الدعم 
التنظيمى للحيلولة دون إضاعة 
وقت أعضاء الفريق. 

يجب أن يتفاعل مدير المشروع 
مع جميع أعضاء الفريق وبخاصة 
رئيس التخطيط. 


المصدر: بيرسون للتعليم (ممتخوع نل مموعوءط) . 
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المهارات المطلوبة 

التسويق, بيئة العمل التجاري» 
اتجاهات تقنية. خبرات من 
مشاريع سابقة» التواصل» تحديد 
الأهداف» تكوين إجماع على 
الآراء. 

قادر على التواصل» متعاطف» 
يمتلك مهارات تقنية 


التحليل الشامل» التواصل» 
تحليل المبادلات» بيئة العمل 
التجاري» البيئة السياسية. 


إدارة الوقت» التنظيم » التواصل . 


التواصل» تكوين إجماع على 
الآراءء» الشخصية الذاتية» 


سوف تعود الفائدة على مدير التزويد نتيجة اكتسابه مهارات 
جيدة في التواصل الاجتماعي. من المعتاد في شركة سيمنز أن يتم 
دعوة الزائرين للمواقع التي تعمل عن بُعد إلى عشاء أو مناسبات 
اجتماعية خلال فترة زيارتهم. نحن نشجع مثل هذه العلاقات 
الاجتماعية لأنها تساعد فى بناء عمل جماعى أفضل. 


قد يحتاج مدير التزويد مهارات تقنية كثيفة أكثر من مدير 
في موقع واحد أي معلومات تقنية» يمكنه بكل بساطة التوجه إلى 
أحد الخبراء وسؤاله عن ذلك. وقد يواجه مدير التزويد للمواقع التي 
تعمل عن بُعد مشكلة في فارق التوقيت بين موقعه والموقع 
اللمزكري» [ذ قد يكوون أعقيلة الفريق المركوى ناما عند التاحة إلى 
معلومات تقنية منهم. لذاء لا بد أن يمتلك مدير التزويد مهارات تقنية 
جيدة وخبرة جيدة أيضاً فى هذا المجال. في الواقع» لقد قام الكثير 
منهم بالمشاركة في المراحل المبكرة في نتائج البرمجة التي سيتم 
إعادة تسليمها إلى فريق البرمجة الذي يعمل عن بُعدء وبالتالي 
سيكونون مدركين لمتطلبات المنتج وهيكلية النظام. 


فكرة مفيدة: 

راقب كيفية تقديم الأشخاص أنفسهم في اجتماع الموقع 
الذي يعمل عن بُعد. 

سوف تتعلم أكثر عن المزودين إذا قام أعضاء الفريق 
بتقديم أنفسهم إلى بعضهم بعضاً وإليك أيضاًء إذ لا بد 
أنهم لم يتقابلوا مسبقا. وفي بعض المواقع» لا يساعد 
تغيير أعضاء الفريق السريع في تكوين علاقات عمل 
طويلة الأمد بين الأعضاء. بما إنك تستثمر فى مدير 
الفروية التشووعك تحيك يضبح منافسا قوياً لك على 
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المدى البعيد» قم بكل ما تستطيع لتكوين فرق ذات 
إنتاجية عالية» واحتفظ بهم للعمل معك لفترة طويلة من 
السدين. 


3-0 نماذج تنظيمية 

تشير خبراتنا إلى أن مديري التزويد يجب أن يكونوا مسؤولين 
عن ثمانية مبرمجين يعملون عن بعد على الأقل» وأن لا يزيد عددهم 
على عشرة؛ ومن الأفضل أن يكون مديرو التزويد جزءاً من الموقع 
المركزي ومقيمين فيه. ولكن يُتوقع أن يقوموا برحلات متكررة إلى 
الموقع الذي يعمل عن بُعد. يلخص الجدول 2-10 عدداً من البدائل 
المتاحة لمدير التزويد الذي يعمل في التنظيم وإيجابيات وسلبيات 
هذه البدائل. 

يتم التحكم بالتواصل والتنسيق لمشروع التطوير الموزع عن 
طريق الفريق المركزي. يتم التحكم بالأنشطة التقنية عن طريق قادة 
الفرق الفنية الموجودين في الفريق المركزي. أما أنشطة المشروع فيتم 
التحكم بها بواسطة مدير الإنتاج ومديري التزويد. ويتم التخطيط 
للمشروع بحيث يتكون من عدد من الفترات البرمجية التكرارية ليتم 
إنجاز جزء من البرمجية في نهاية كل شهر. ويتم التخطيط للأهداف 
التي سيتم تحقيقها نهاية كل شهر مركزياً عن طريق خطة بناء 
المشروع. 

يجب أن يقوم كل فريق برمجي بتحقيق المخطط المفصّل في 
نهاية كل مرحلة برمجية؛ وبدعم من مدير التزويد. وتكون المواعيد 
المتفق عليها للتسليم ثابتة» لكن سيكون هناك تداخل بين مواعيد 
التسليم مستقيلا. 
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الجدول 2-10: الخيارات البديلة لمدير التزويد 


موظف لدى فريق- مقيم في فريق الإيجابيات السلبيات 

مركزي مركزي سيطرة قوية تواصل أقل مع 
المهندسين العاملين 
عن بُعد 

مركزي يعمل عن بُعد # معلومات أقل # تواصل أفضل مع 


عن المشروع المهندسين الذين 
التواصل يعملون عن بُعد 


ا تكاليف المعيشة 
يعمل عن يُعد مركزي ##معلومات أكثر تكاليف أكبر 
عن المشروع يتحملها المزود 


9 التواصل 

يعمل عن بعد يعمل عن بُعد سيطرة أكبر على # معلومات أقل 

الفريق الذي يعمل عن المشروع 

عن بُعد "ا التواصل 
اعقناذا علق 'فااسيى»: تعتقد أن البديل الأقضا هر أن يكون 
مدير التزويد جزءاً من الفريق المركزي وموجوداً فيه. وسوف يكون 
هناك رحلات متكررة إلى المواقع التي تعمل عن بُعدء خصوصا في 
الاجتماع المتعلق ببداية دورة جديدة وفي عرض نتائج نهاية فترة 
واحدة إلى المواقع التي تعمل عن بُعد في كل شهرء أو بمعنى آخرء 
يُخصِّصٌ ما نسبته 25 بالمئة من وقت عمل مدير التزويد للمواقع التي 
تعمل عن بُعد. إضافة إلى ذلك». قد يقوم الخبراء التقنيون في الموقع 
أو مراجعة وتدقيق إنجاز الفريق الذي يعمل عن بُعد. إن قيام الفريق 
الذي يعمل عن بُعد بعرض شهري للعمل من شأنه مساعدة مدير 
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التزويد على تقدير سير أداء العمل للفريق» ويعمل عادة على زيادة 
ثقة أعضاء الفريق بأنفسهم لأنهم يتطلعون إلى التقدم في العمل على 
الصعيد الشخصي والتقدم الإجمالي للمشروع . 


يفضل المزودون توكيل شخص من فريق العمل لديهم في 
الموقع المركزي حتى بعد البدء بالبرمجة. إذ يستعينون بهذا الشخص 
لسد الفجوة في التواصل بين الفريق المركزي والفريق الذي يعمل 
عن بُعد. على الرغم من أن هذه الوظيفة مفيدة» غير أننا لا نتوقع أن 
يتمكن هذا الشخص من تغطية الوظائف التي تم تحديدها لعمل مدير 
التزويد كلياً. قد يمتنع الفريق المركزي عن دفع راتب لهذا الموظف 
وذلك لوجود عدد كافٍ من الموظفين العاملين كمديري تزويد. 
ويحكن أن بعل هذا الموظف كبديل' إذا كان مدير الترويك مغرلا 
في مشاريع أخرى في مواقع تنظيم مركزية عدة في نفس الدولة» 
ويستطيع هذا الموظف العمل في مشاريع متعددة. وقد لاحظنا أن 
مزودينا الداخليين يستخدمون هذا الموظف فى الولايات المتحدة 
بشكل فعَال للمساعدة في توجيه فرق العمل في الموقع المركزي في 
المرحل المبكرة من المشروع. ولاحظنا أيضاً أنهم في العادة يغيّرون 
أماكن وجود أعضاء فرق العمل في الولايات المتحدة برفقة أسرهم. 
وهذا من شأنه الحد من الشعور بالغربة وتجنب الحاجة إلى القيام 
برحلات متكررة إلى بيوتهم في المراحل المبكرة للمشروع. 


ومن الدراسات التي أجريت في شركة سيمنزء خرجنا باعتقاد 
أنه من المفيد نقل فرق العمل من الموقع المركزي إلى مواقع 
التنظيمات البرمجية التي تعمل عن بُعد كمندوبين طويلي الأمد. ومن 
الممكن تطبيق هذا في شركة سيمنز لأن المزودين هم عبارة عن 
شركات فرعية. ويكون هؤلاء المندوبون موظفين موثوق بهم في 


236 


الشركة المركزية ويتم اختيارهم عادة للمساعدة في إنشاء فرع للشركة 
في الدولة الأجنبية. وبصفة عامة» تساعد معظم التبادلات التي تتم 
بين فرق العمل في بناء العلاقة بين الفرق المركزية والفرق التي تعمل 
عن بُعدء خصوصاً إذا لم تسر عملية التطوير أو التواصل على النحو 
المطلوب» إذ يتناقص التواصل بين الفرق المركزية والفرق التي تعمل 
عن بُعدء ويمكن أن يتم إنجاز هذا عن طريق التبادل الفعلي لفرق 
العمل. يجب أن يتم اختيار فريق العمل الذي سيتم تبادله بحيث 
يمتلك مهارات التواصل» إذ سيعمل أفراده كحلقة وصل بين الفرق 
اللمزكرية .والفزق الى عمال عن لخ 


اعتماداً على خبرتناء نعتقد أنه من الضروري وجود شخصية 
تفاعلية تقنية للحفاظ على مشروع التطوير الموزع في مساره. لذلك» 
وعلى الرغم من أن التوثيق الجيد أمر في غاية الأهمية» غير أننا لا 
1-0 يمكن أن يكون ناجحاً للمشاريع المركبة في تطوير البرمجيات. 


فكرة مفيدة: 

قم بإرسال أعضاء فريق العمل الموثوق بهم إلى موقع 
جديد يعمل عن بعد. 

ناقشنا فى هذا الفصل أهمية مدير التزويد الذي يعمل 
لدى الفريق المركزي الذي يقضي جزءاً من وقته في 
مواقع البرمجة التي تعمل عن بُعد (على سبيل المثال 
5 بالمئة). وقد ناقشنا أيضأً قبل ذلك أهمية عمل 
الأعضاء المميزين في الفريق الذي يعمل عن بُعد في 
الفريق المركزي خلال المراحل الأولى من العمل. 
إضافة إلى ذلك» ضع بعين الاعتبار نقل أعضاء من 
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لقزيق: الفركرق: إلى خوائع ميسة:افي الفريق الذي 
يعمل عن بُعد. في بعض الأحيان يكون انخفاض عامل 
لتكلفة السبب المؤدي إلى تعيين أفراد ليسوا من ذوي 
لخبرة تماماً. بوجود فريق عمل موثوق به في التنظيم 
لذي يعمل عن بُعدء يمكن أن يقوم أفراده بالمساعدة 
والمساهمة فى الأنشطة المختلفة التى سوف تساعد فى 
تسريع أداء الفرق التي تعمل عن بُعد في العمل في 


مشروعك. 


4-0 قضايا تعدد الثقافات 


لاحظنا في العديد من المشاريع أن المتغيرات الثقافية تكون 
عامل مؤثراً في مشروع التطوير الموزع (1993 ,1ءمم1>0). وقد تعمل 
هذه العوامل على تقوية أو إضعاف سير المشروع حسب طريقة 
إدارتها. في شركة سيمنز» يمكن أن تنبع العوامل الثقافية من عدة 
دول ومن ثقافات مختلفة للشركات» لأن شركة سيمنز امتلكت العديد 
من الشركات بمرور الوقت. 


قد تؤثّر العوامل الثقافية في قيم أعضاء الفريق البرمجي بما 
في ذلك الالتزام بالمواعيد والالتزام بالحد الفاصل بين الوقت 
المخصص للعمل والوقت الشخصي وحل النزاعات» وغير ذلك. 
طسبنا "المقالة: كنم اوذاد فطل العمل بسي الثرات معد 
تسليم المشروعء قد يتهم أعضاء الفريق الذي يعمل عن بُعد 
بعضهم بعضاً بالتقصير ويتذمرون بقولهم «هم في إجازة بينما نحن 
بحاجة لإنجاز العمل». 
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لقد أكدنا الحاجة إلى مدير التزويد لاستيعاب الأمور الثقافية 
والقدرة على التواصل مع أعضاء الفريق. وعلى كل حال» تمتد هذه 
الحاجة إلى جميع أعضاء الفريق. فقد لاحظنا أن المشاريع الناجحة 
تبني ثقافتها الخاصة التي يتم تبنيها من ثقافة الدولة والشركة. ويتم 
تكرار التواصل بشكل مستمر وبطرق مختلفة للتواصل وذلك 
للمساعدة في التعليم بأساليب ولغات مختلفة. ويقوم أعضاء فرق 
العمل من المواقع المتعددة بزيارة بعضهم يعضا بشكل :دورى: 
يتعرفون على بعضهم خارج نطاق العمل. 


وقد لاحظنا أيضاً أن المشاريع الناجحة تستثمر الجهد في عملية 
الأساسية لمدير التزويد» لكنه مفيد جداً للفريق كله. وعادةً ما تنعكس 
عوائد هذا التدريب على النواحي العملية كتحديد وسيلة مشتركة لعقد 


فكرة مفيدة: 

قم بتشجيع المشاركة في الأداء الجيد. 

من المفيد أن يكون هناك مقارنات بين أعضاء فريقك 
والمزودين. اجعل هذه المقارنات محَفّزاً إيجابياً 
وليس سلبياً عن طريق تشجيع «المشاركة في الأداء 
الجيد». إذا تبين أن إحدى الفرق تستخدم عملية أو أداة 
أو تقنية مبتكرة» قم بنشر ذلك بين الفرق الأخرى بحيث 
يتم التعلم من هذه الخبرة. لا توجه السؤال الاتي: «لماذا 
لا يستطيع فريقك أن يكون بمستوى الفريق 8؟» إذا 
كنت تقوم بإدارة فريق مصدره أكثر من مزوّدء يمكن أن 
يكون بيتهم تنافس في العمل» لذا يجب أن يتصبٌ 
اهتمامك على استخدام أفضل الممارسات من أجل 
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مشروعكء وكن متأكداً أن جميع أعضاء الفريق يملكون 
دوافع للعمل ومنتجون ذوو مستوى متقدم. 


١5-0‏ لملخص والاستنتاجات 


بصفتك مدير تزويد» أنت عضو مهم في فريق المشروع 
للمساعدة في سد الفجوة في عملية التواصل مع الفريق الذي يعمل 
عن بُعد. وسوف تكون نظرتك للعلاقة مع مزوديك على أنها علاقة 
طويلة الأمد. ومع مرور الوقت يصبحون امتدادا لشركتك الخاصة. 
ستنمو قدراتك في التعويض عن بُعد المسافات والثقافات واللغة التي 
لم تتعرف عليها في المشاريع التي يتم إنجازها في موقع واحد. 
سوف تكون مسؤولاً عن التقدم في سير المشروع في فريق البرمجة 
الذي يعمل عن بُعد وفي علاقاتهم في العمل مع الموقع المركزي. 
باختصارء يتمثل عملك كمدير تزويد بأنك «مدير مشروع برمجي 
متنقل؟2. 


6-0 أسئلة للمناقشة 

1. ماهي المهارات المطلوبة من مدير التزويد» وفي أي المجالات 
يتم استغلال هذه المهارات؟ 

2 كيف يتم توظيف أعضاء الفريق الذي يعمل عن بُعدء وكيف 
تتم مقابلتهم وتخصيص الوظائف لهم؟ 

3. أذكر بعض العوامل الثقافية التي قد تؤثر في تقويم فريق 
العمل المكوّن من عدة دول تعمل في المشروع. 

4. كيف يقوم مدير التزويد بالتواصل مع أعضاء الفريق الذي 
يعمل عن بُعد؟ وما عدد المرات التي يقوم بها المدير بزيارة 
الموقع الذي يعمل عن بُعد؟ 
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القسم الرابع 5 


المراقبة والتحكم 


الفصل الحاوي عشر 


ضمان الجودة 


أنيطت مسؤولية ضمان الجودة في مشروع نظام إدارة المباني 
الآلي إلى رون (805) مؤخراء وتم إعلامه أن معظم عمليات البرمجة 
ستتم فى مدينة بانغالور (©:ملووصة8). كان رون محتاراً حول الطريقة 
التي يمكن أن يضمن بها جودة البرمجيات التي يبرمجها فريق عمل 
لم يقابله.من قبل وليس لديه أي تأثير فق :عمليّة البرمجة التي 
يقومون بها. 


نبحث في هذا الفصل في الاستراتيجيات التي يمكن اتباعها 
لمزاقة جودة عملي لطوير البرمسنيات] المورعة المرزاكر وسودة العم 
البرمجي. ويتم تحسين هذه العملية عن طريق قياسات ومراجعات 
مستمرة يُحدّد من خلالها الزمان والمكان اللذان تمت خلالهما عملية 
البرمجة الخاطئة للعملية؛ ومن الاستراتيجيات المتبعة لتحسين جودة 
المنتج القيام بتحليل بيانات المقاييس الأساسية ومنع حدوث العيوب 
والمشاكل في النظام والاختبار المستمر. 
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1-1 تمهيد 
تعرّف هيئة مهندسي الكهرباء والإلكترونيات 005515 جودة 
البرمجيات على أنها : 
المتطلبات المحددة. 
الحاجات المتوقعة من العميل. 
تعريف ضمان الجودة (ى0م)) الذي يلسجم مع هذه التعريفات 
هو: 
1. جميع الأنماط المنتتظمة والمخطط لها للعمليات الضرورية لتوفير 
ثقة كافية بأن المنتج أو العنصر يلبي المتطلبات التقنية 
2 مجموعة الأنشطة المصممة لتقويم العمليات المستخدمة في 
تطوير أو إنتاج المشروع . 
غير أننا نجد أن تعريف هيئة مهندسى الكهرباء والإلكترونيات 
لجودة البرمجية جيدة» فإننا نرى بأن تعريف ضمان الجودة يحدد 
هدف الضمان بأن يتم تحقيق المتطلبات التقنية للمؤسسة. وفي رأيناء 
تشمل أنشطة ضمان الجودة مقاييس لضمان أن متطلبات المؤسسة 
تعكس بدقة احتياجات العميل أو المستخدم. ونحن نؤمن بما تحمله 
معتقدات منهجية البرمجة السريعة (116ع4) أن المستخدمين والعملاء 
ليسوا قادرين دائماً على الوصف الدقيق لاحتياجاتهم؛ المقولة القديمة 
بمجرد أن أراه». نعيد بالتالى تعريف هيئة مهندسى الكهرباء 


والإلكترونيات لضمان الجودة ليصبح: 
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«هو جميع الأنماط المنتظمة والمخطط لها للعمليات الضرورية 
لتوفير ثقة كافية بأن المنتج أو العنصر يلبي المتطلبات التقنية 
والاحتياجات المتوقعة من العميل أو المستخدم». 
تتضمن عملية ضمان الجودة الإجابة عن الأسئلة الآتية: 
- كيف يمكننا أن نتأكد أننا أنتجنا ما نحتاجه ونريده بدقة؟ 
- كيف يمكننا أن نتأكد أننا أنتجنا نظاماً يحقق المتطلبات 
المتوقعة؟ 
- كيف يمكننا أن نتأكد أننا أنتجنا نظاماً يعمل كما هو متوقع 
منه في الوقت ال حالي ومستقبلا؟ 
- كيف يمكننا أن نتأكد أننا أنتجنا نظاماً لن يقوم بعمل أي أمور 
غير متوقعة منه؟ 
نصف في هذا الفصل الأآمور المتعلقة بضمان الجودة في 
مشاريع تطوير البرمجيات الموزّعة المراكز وكيفية التعامل مع هذه 
الأمور ومناقشة صيانة البرمجيات التي أنشئت من خلال تطوير 
البرمجيات المورّعة المراكز. ولن نناقش تفاصيل ضمان الجودة 
المتعلقة بتطوير البرمجيات الموزرّعة المراكز والتي لا تختلف عن 
تفاصيل الجودة في المشاريع المنتظمة أو التفاصيل التي ليس لها تأثير 
في الأنشطة التي تم وصفها في هذا الكتاب. 
1-1-1 ضمان الجودة في سياق شامل 
لماذا تختلف عملية ضمان الجودة فى سياق شامل؟ لماذا لا 
بكوة :ذلك ناض 13 وإضععا سيكها ‏ صارما بى عمل فا الحو 
للمشروع المستهدف؟ فقد تكون عملية ضمان الجودة في تطوير 
البرمجيات الموزّعة المراكز مختلفة لنفس الأسباب التي تم ذكرها 
مرات عديدة في هذا الكتاب. في المشاريع المنتظمة» هناك شبكات 
أمان غير رسمية تعدّل القصور في العمليات الجارية. وهذا يعني أن 
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عملية ضمان الجودة ليست العملية الأساس التي تعيد الأمور 
لنصابهاء بل هي عمليات التفاعل المتقاربة والثابتة من قبل أعضاء 
الفريق للقضايا التي تظهر على السطح (أو ربما كان ذلك ضمن جزء 
من عملية ضمان الجودة). إن شبكات الأمان هذه غير موجودة فى 
عملية تطوير البرمجيات المورّعة المراكز. إضافة إلى ذلك». قد 06 
الوقن لكمرى: أعير دزي رسيا اتظرين ارترمتجياك: هر ( ج04 براك 
يشبه ذلك سيارة نقل صغيرة يرتبط بها مجموعة من العربات تسير 
على الطريق السريع» وعندما يقوم السائق بتعديل الاتجاه؛ء يصبح 
التعديل أكبر وأكبر حين انتقاله من عربة إلى أخرى. وقد تؤدي 
التعديلات البسيطة في المسار التي يقوم بها السائق إلى نتائج كارثية 
على العربات. وينطبق هذا على عملية تطوير البرمجيات الموزّعة 
المراكز. 

عند نقل مواصفات المشروع إلى الفريق الذي يعمل عن بُعدء لا 
يمكن التأكد مما إذا كان أعضاء الفريق قد أدركوا طبيعة المهام المنوطة 
بهم. في المشاريع المنتظمة» يتقابل أعضاء الفريق وجها لوجه. كما 
يتم تأسيس علاقات في العمل تجعل التواصل أكثر سهولة؛ عندئذ 
ستتمكن من الانتباه إلى الملاحظات الضمنية التي تشير إلى وجود 
ارتباكات غير مريحة في المهام. وفي عملية تطوير البرمجيات الموزّعة 
المراكز يتم إرسال المواصفات لاسلكيا من خلال الشبكة الإلكترونية» 
أو عن طريق شبكة مرئية خاصة؛ وستكون على يقين أن الفرق 
ستخبرك إذا كان هناك مشاكل أو استفسارات تتعلق بالمواصفات 
المستلمة. مقارنةٌ بالمشاريع الموزّعة» توفر المشاريع المنتظمة فرصاً 
متزايدة لامتلاك رؤية لتنفيذ المهام الفردية. عليك أن تتعرف على 
الأعضاء المميزين في الفريق وأسلوب العمل الذي يتبعونه ومدى سير 
الأمور بشكل جيّد. ولا تساعد هذه المعلومات في تحديد القضايا 
الأساس وحسب,. بل في إيجاد حلول لها بشكل سريع. 
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عند اكتشاف أي مشاكل في مشروع تطوير البرمجيات المورّعة 
المراكزء من الصعب معالجتها كما في المشاريع المنتظمة. وإن من 
الأمور الأكثر صعوبة تحديد الشخص الواجب إناطة حل المشكلة لهء 
ومن الصعب ضبط الجدول الزمني وتحويل المهام إلى المحاسب 
لتقدير أي مشاكل في المهام أو جهد جديد غير متوقّع» وبشكل عام 
لا تجعل أي مشاكل في المهام تؤثر في سير العمل. اعتماداً على نوع 
المهمة (على سبيل المثال عدم فهم للمتطلبات» أمور نحوية» أو 
أمور تتعلق بالسلوك)» سوف يتم اكتشافها في أوقات مختلفة. كلما 
كنت بعيداً عن المشكلة عن ظهورهاء كان صعباً عليك تصحيح 
مصدر المشكلة. وليس من غير الشائع توكيل مهمة حل مشكلة ما 
إلى أكثر من شخص لحلها قبل أن يتم حلها بالفعل. وقد صاحب 
إعادة التكليف بحل المشكلة تحقيق بهاء وكذلك تحقيق بأي شخص 
يكون قد تسبب بالمشكلة. هذا وقد يحتاج ذلك وقتاً إضافياً على 
حساب المهام الآخرى. وفي نهاية المطاف قد يحتاج الأمر إلى 
مفاوضات أو تعاون من أعضاء الفريق الذين يصعب أن يؤدوا عملهم 
بشكل فاعل. وقد يؤدي إعادة تكليف المهام إلى تأثير غير جيد في 
سير المشروع. وإذا كانت إحدى الفرق تعمل على تطوير أحد الأمور 
في مرحلة حرجة لتأثيرها في المخطط المستقبلي للمشروع» فإن 
التأخر في تسليم هذا الجزء قد يعني وجود فرق أخرى بلا عمل في 
انتظار التسليم من فريق آخر. 


2-1 قياس جودة العمليات 


أصبح التنسيق والتحكم أكثر صعوبة بسبب التوزيع الجغرافي 
للفرق. يجب أن نجعل عملية أداء العمليات تؤدّى بطريقة تضمن 
الجودة العالية للمنتج. ومن الصعب التأكد من أن ممارسات محددة 
سوف تكون فعّالة في مشروع معيّن بسبب الاختلاف الجذري 
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لمشاريع تطوير البرمجيات المورّعة المراكز عن بعضها بعضاً. في 
مشاريع تطوير البرمجيات الموزعة المراكز في شركة سيمنز»ء لم نجد 
أي علاقة بين ممارسات معينة تقوم بها الشركة وبين نجاح المشروع. 
ذلك يعنى أننا بحاجة ماسة إلى تعريف محددات تمنحنا مؤشرات 
تحذيرية مبكرة عند الحاجة إلى إجراء أي تعديلات على أي عملية 
من عمليات المشروع. ونناقش في هذا الفصل بعض الممارسات التي 
تم استخدامها بنجاح والمحددات التي قد تكون مفيدة وكيفية 


1-2-1 تحديد العمليات 

إن من الأمور الحسنة أن تمتلك شركتك مجموعة من العمليات 
لهندسة البرمجيات (5820)». وأن يكون لديها مجموعة نموذجية 
ومحددة من العمليات من أجل تطوير برمجية معينة؛ قد تحتاج الكثير 
من التفاضيل للتعديل»: وقد يوجد عفن التفاصيل التي لم .يتم 
معالجتها نهائياًء أو قد لا تناسب الفريق الذي يقوم بعملية تطوير 
البرمجيات الموزّعة المراكز في المشروع. على سبيل المثال» تصف 
العمليات التي تُجرى على هندسة المتطلبات الطريقة التي يتم بها 
صياغة المتطلبات بحيث تسهل العملية الالية للاختبار. ويجب تعريف 
جوانب محددة بشكل مختلف من مشروع لآخر وفقاً لطبيعة 
المشروع» كالبنية التحتية المستخدمة للمشروع والممارسات الإدارية 
التفصيلية والمستوى التدريبي التطويري اللازم للفريق وسرعة إنشاء 
المشروع والعمليات اللازمة له» وغير ذلك. ويتم اختيار هذه 
العمليات بحيث تراعى الموازنة بين المخاطر والنفقات. وكما تمت 
مناقشته في الفصل الع يزه (تحليل المخاطر)ء يجب أن يتم الاختيار 
أو إعادة تكييف العمليات بمعرفة تامة بخصائص المشروع (سُمَي 
ذلك ب «ملف المخاطر» في الفصل السادس من هذا الكتاب). وفي 
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حقيقة الأمرء فإن تعريف هذه العمليات ما هو إلا بداية. فالاختيار 
هو عملية تكهنية تعتمد دقتها على الكثير من العوامل. ومن الحكمة 
أن تفكر في المدى البعيد وتضع خططاً للطوارئ بالإضافة إلى عملية 
الاختيار. فما مدى القدرة على إجراء تعديلات منطقية وقابلة للتطبيق 
على العمليات إذا كان المشروع لا يسير كما هو متوقع (لمزيد من 
التفاصيل» انظر الفصل السادس من هذا الكتاب)؟ 


2-2-1 تحديد المعايير 

بعد أن يتم تحديد العمليات» يجب أن تحدد الآلية التى 
ستستخدم لمراقبة هذه العمليات. ومن الأمور التي تم الاستشهاد بها 
مرات عديدة صعوبة الحصول على صورة واضحة لعملية التقدم في 
سير العمل والوضع الحالي لمشروع تطوير البرمجيات الموزّعة 
المراكز. ولا تظهر المشاكل عادة إلا فى المراحل النهائية للعمل» 
وهذا يؤدي إلى اختلال كبير في العمل (تخيل المثال السابق للشاحنة 
الصغيرة). ونحتاج إلى وضع معايير نتمكن من خلالها الحصول على 
مؤشيرات تحذير مبكرة يأن العمل لأيسير كما هو فخطط لها 
الحصول على هذا بسهولة. ويجب أن نكون قادرين على وضع دليل 
قوي ومتماسك لذلك (أبعد من الأهداف الأساس والأسئلة 
والأسلوب المعياري)؛ لكن للأسف كل ما نستطيع فعله هنا هو 
الاستفادة من بعض الاستنتاجات من تجارب سابقة. ومن الأمور التى 

يمكن مراقبتها وتعتبر من المؤشرات التحذيرية لأمر ما: 
© زيادة التواصل: عندما يجد الناس مشاكل في عملهم» يبدأون 
أكثر من الطبيعي» أو يعقدون اجتماعات مباشرة مع بعضهم 
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بعضاً. فكيف يمكن أن يساعدنا ذلك؟ فى الحقيقة إذا كنت 
قادراً على ملاحظة أي من هذه الأمور ‏ كارتفاع مفاجئ في 
عدد الرحلات غير المخطط لها من قبل الأعضاءء أو زيادة 
فى عدد مستخدمى مزودي الخدمة» وغير ذلك - ربما يستحق 
ذلك البحث في سني حدؤته! ويمكن تفسير بعض هذه 
الأمور عن طريق الجدول الزمني (على سبيل المثال» قد يزداد 
التواصل خلال الأوقات التى يكون فيها تداخل في نهاية 
مرخلة سابقة وبذاية مزحلة جديذة أو قبل مواعيد. التسليه) 
لكنها قد تكون مؤشرات على حدوث أمور غير طبيعية. 

© انخفاض غير طبيعي في عملية التسليم عند نهاية إحدى 
المراحل: بسبب الطبيعة السلسة لعملية تخطيط العمليات» 
فمن الطبيعي أن تكون مواعيد تسليم المراحل قابلة للتعديل 
بشكل ماء لكن يتم ضبط ذلك تماماً مع مرور الوقت. وإذا 
كان تسليم العمل من إحدى الفرق أقل بكثير ما هو متوقع» 
فمن الحكمة البحث فى سبب ذلك. فقد تتسبب مجموعة من 
فرق "العم .ةا التاحير احيانكء ومن الأفمل أن يعسن 
الفريق المركزي مبكراً بحيث يكون مدركاً لأي تغييرات ويقوم 
بالتعامل معها. 

© الروح المعنوية لفريق البريجة: لاحظنا وجود علاقة قوية بين 
توقع فريق البرمجة لسير العمل والبرنامج الزمني الفعلي للعمل 
(وعلى العكس من ذلك» هناك علاقة ضعيفة بين توقع 
الرؤساء لسير العمل والبرنامج الزمني الفعلي للعمل). إذا كان 
تتبّع مستوى الإحباط عند فريق البريجة ممكنأء سيكون ذاك 
مؤشراً جيداً للوضع الحالي للأمور. وسيعلم الأشخاص الذين 
يتعاملون مع الأمور التي تحيط بها المشاكل بشكل يومي أن 
هناك مشكلة عالقة قبل معرفة الإدارة مها. إذ من السهل أن 
تشعر الفرق بعدم الراحة إذا تُركت من دون عملء أو إذا 
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شعرت بوجود عمل مجهد. وهذا مؤشر على تخطيط ضعيف أو 

أداء ضعيف من إحدى الفرق الأخرى أو مشاكل في 
المتطلبات أو التصميم. 

#يعر نص و الطدات آر لصم : على الرغم من أن هذا 

يكتشف في مرحلة مبكرة فى الخرو ديد كمي ايده 

غير أنه من الحكمة الببغت: في الأسبات والتأثيرات لهذه 

التغييرات إذا كان هناك تغيير مستمر في المتطلبات أو التصميم 

يجب ملاحظة أن فريق العمل الجديد الذي يعمل عن يُعد 

يحتاج إلى وقت للوصول إلى أفضل إنتاجية. ومن خبراتنا السابقة في 

مشاريع التطوير المورّعة لشركة سيمنزء قد تحتاج هذه الفرق الجديدة 

إلى وقت من ستة إلى اثني عشر شهراً لتحقيق أفضل إنتاجية. ويجب 

أن تكون الأهداف التي يؤمل تحقيقها في أول مرحلة من مراحل 

العمل متواضعة ويزداد حجمها بمرور الوقت. 

3-2-1 تحسين العمليات 

بما إنك المدير المركزي لضمان جودة عمل الفريق» تقع على 

عاتقك مسؤولية التحسين المستمر لعملية التطوير الموزّعة. ويجب أن 

يتم أداء هذا بشكل تدريجي وبحذر بحيث لا يتم التشويش على سير 

عملية البرمجة. وسوف تعمل على هذه التحسينات مع الفريق 


المسؤول عنها الذي يعمل عن بُعد. كما يتم أيضاً عرض هذه 
التحسينات مع الإدارة المحلية التي تعمل لديها. 


3-1 قياس جودة المنتج 


يتم قياس جودة المنتج عن طريق تتبع عدد العيوب من خلال 
الاختبارات الإضافية للإصدار السابق (2002 ,0ؤذانه2). يتم الحصول 


على عدد العيوب باستخدام أداة للتعامل مع التغيرات بحيث تكون 
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قادراً على تحديد الأولويات وعدد العيوب وحالاتها التي بلغ عنها 
فريق الاختبار. ستكون لديك معايير لقياس الجودة مرتبطة بقبول 
العميل للمنتج ؛ على سبيل المثال» الن يتم تسليم أي منتج إذا كان 


بعل). 


1-3-1 أنواع العيوب 
إن مصطلح «عيوب» هو أكثر شمولاً من مصطلح «خطأ»؛ 
ويعرّف على أنه أي ار مضي الل هن «مواءمة الأهداف 
المطلوبة». وكما تم مناقشته سابقاًء يتم تعريف مواءمة الأهداف 
المطلوبة بأنه قدرة المنتج على تحقيق التوقعات المطلوبة من 
المستخدم. لذلك» يمكن تحديد أنواع العيوب كما يأتي : 
- أخطاء برمجية: أخطاء في لغة البريجة. 
5 خصائص غير صحيحة: وهي أخطاء ء في عملية التصميم 
المنطقي؛ ويتم الإشارة إليها على أنها أخطاء ذات دلالات 
لغوية غير صحيحة. 
ِ- خطأ في فهم الخصائص: يكون ذلك نتيجة فهم خاطئ من 
المبرمج أو المصمم لمتطلبات العميل. 
- سلوك النظام: يظهر ذلك عندما يكون أداء النظام ضعيفاًء أو 
عدم ظهور نهايات متوقعة للبرمجية» أو أن لا يكون أداؤه كما 
هو متوقع تحت ظروف معينة (على سبيل المثال» عند إجراء 


2-3-1 أمور تتعلق بجودة المنتج في مجال تطوير البرمجيات 
المورّعة المراكز 


إذا أعدنا النظر في العيوب السابقة» سنرى بوضوح أموراً أخرى 


254 


تحافظ على جودة المنتج في ضبط عملية تطوير البرمجيات الموزّعة 
المراكز. ويحدث ذلك عندما يُحدّد مترجم لغة البرمجة وجود بعض 
الأخطاء في لغة البرمجة (مثلاء عدم وجود توافق في عملية ربط 
المتغيرات)» ذلك يعنى أنه من السهل تحديد هذه الأخطاء حتى فى 
عيلة لين الو بع لني اناف نكن الخطاء الات 
اللغوية هي أكثر صعوبة بكثير. يجب أن يكون لدينا أساليب مناسبة 
للإحاطة بحالات الاختبار التي نجريها للكشف عن أخطاء الدلالات 
اللغوية في عملية تطوير البرمجيات الموزّعة المراكز وتصحيحها. ففي 
حين ينطبق هذا أيضاً في المشاريع المنتظمة» غير أن احتمالية 
مواجهة مثل هذه المشاكل يكون أكبرء واحتمال أن تؤدي تأثيراتها 
إلى حدوث عيوب أكبر بكثير في عملية تطوير البرمجيات الموزّعة 
المراكز. فقد تؤدي المفاهيم المختلفة بين الفرق مثل الدولار 
الأميركي مقابل اليورو (كما حدث في المركبة الفضائية التي كان 
يفترض أن تهبط على المريخ) إلى أخطاء منطقية ومشاكل محصورة 
في فريق واحد. 


تكون احتمالية حدوث فهم خاطئ أكبر عند ضبط عملية تطوير 
البرمجيات الموزّعة المراكز. عندما يكون المشروع منتظماء لا يكون 
من غير الشائع إجراء مقابلات مباشرة من أجل زيادة المواصفات. 
ولا تكون هذه المقابلات أكثر فاعلية وحسبء بل إنها تتيح قياس 
مستوى الاستيعاب لدى الشخص المتلقي أيضاً. وقد ذكرنا سابقاً أن 
شبكة الحماية لا تكون متوفرة فقط في مشاريع تطوير البرمجيات 
المورّعة المراكز؛ إذ يعتمد على أساليب ضمان الجودة في مشاريع 
تطوير البرمجيات الموزرّعة المراكز. نأمل أن يكون قد تكوَّنَ لديك 
الآن إدراك أفضل عن السبب الذي يجعل الحصول على جودة المنتج 
في مشاريع تطوير البرمجيات الموزّعة المراكز أكثر صعوبة. 
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3-3-1 الاستراتيحيات المتبعة للحصول على الجودة فى 
مجال تطوير البرمجيات المورّعة المراكز 1 
في عمليات التطوير الموزّعة» يُنصح باتباع وسائل الاختبار 
التلقائي المحوسب للغة البرمجة. سوف تقوم الفرق التي تعمل عن 
بُعد بعمل الاختبارات مع أعضاء فريقهم المحلي» ويمكن استخدام 
هذا الأسلوب على شكل فريق ثنائي من المبرمجين. على كل حال؛ 
من المفيد في عمليات التطوير الموزّعة وضع أسس ومعايير للغة 
البرمجة التي يستخدمها جميع أعضاء فريق البرمجة. إذا تم اختبار 
البرمجة المستخدمة باستخدام أداة لاختبار وجود اختراقات للأسس 
والمعايير الموضوعة للغة البرمجة» سيكون من الأسهل على أي 
عضو من أعضاء الفريق فهم البرمجة الموضوعة وسيتم اكتشاف 
العيوب قبل تنفيذ عملية الدمج. 
نعرّف «أسلوب العمل الممتد)» على أنه النموذج الذي تتم فيه 
برمجة كل المكوّنات عن بُعد ومن ثم يتم جمعها معاً في الموقع 
المركزي لإجراء عمليتي الدمج والاختبار. لذلك» يتم إجراء عدة 
مراحل من الاختبارات في الموقع الذي يعمل عن بُعد وفي الموقع 
المركزي. وتتضمن بعض الممارسات الجيدة للاختبار والتي ينصح 
بها ما يأتي : 
- يقوم الفريق المركزي بعمل مجموعة اختبارات القبول والمستمدة 
من المتطلبات الوظيفية ذات الأولية القصوى. 
- يقوم الفريق الذي يعمل عن بعد بعمل مستويات متعددة من 
الاختبار التلقائي كجزء من مهامه في كل مرحلة عمل. 
#- عيقوم الفريق المركري تتحديد وقظبيق اعتبارات للم في 
الموقع المركزي. ويتم تحديد هذه الاختبارات عندما تكون 
إحدى المراحل على وشك الانتهاءء ويتم تطبيقها في نماية كل 
مرحلة. 


226 


من الأفكار الجيدة استخدام النماذج الأولية لمختلف الغايات. 
ويفيد استخدام نموذج أولي لواجهة المستخدم أحياناً» وذلك لتأكيد 
المتطلبات التي نحتاجهاء وللتأكد من أن الفرق التي تعمل عن بُعد 
قد استوعبت هذه المتطلبات بشكل عام. إضافة إلى ذلك» ننصح بأن 
يتم برمجة «شريحة عمودية» من هيكلية النظام أولاء وذلك لتسهيل 
إجراء اختبارات مبكرة على خصائص المستويات المختلفة للنظام» 
والتأكد من الجزء الأكثر خطورة من الهيكلية» والتأكد أيضاً من أن 
الفرق التى تعمل عن بُعد قد استوعبت المتطلبات بشكل كامل 
رايت تأده على تطبيق التصميم. قمنا إلى جانب هذه الأمور 
بإجراء اختبار تحليلي ثابت (من دون تشغيل النظام) على هيكلية 
النظام وعدد مختلف من الأجزاء البرمجية الأساسية. يمكن أن يتم 
إجراء ذلك يشكل كلناي مسوسيه سنيتم التاكدنن أن تناصيلن 
التصميم قد تم إنجازها بشكل فاعل إذا توفرت أداة فعّالة لآداء ذلك. 


من المفيد إضافة عملية الاختبارات التي تُجرى لملاءمة ما يتم 
تسليمه مع المواصفات كجزء من حزمة العمل في نهاية كل مرحلة 
معيّنة على الرغم من أنها تشكل عبئاً إضافياً على الفريق المركزي. قد 
وجدنا أن اتباع أسلوب الاختبارات التي يقوم بها المبرمجون 
تساعدهم على فهم وتحديد المتطلبات الأكثر أهمية. 


نشو باتع ال كباله تمي خعاتاطة لمر جنا [المقطلياك من قن 
خبراء في المجال للتأكد من عدم إغفالنا أي متطلبات أساس» وأن 
المتطلبات كما تم تصورها تعبر عن حاجات ورغبات المستخدم» 
وذلك كجزء من العمليات التي تجرى على المتطلبات. ويساعد هذا 
شكل كر في نيينها إلى الحصول :علي التموفع نطاوب زيؤقئ 
التمثيل المرئي باستخدام لغة النمذجة الموحدة إلى تعبير بسيط بحيث 
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يتمكن الأشخاص غير التقنيين من فهمه. كما يتم من خلالها إجراء 
اختبارات تلقائية وتزيد من القدرة على إجراء التعديلات وتغطية 
مجالات الاختبار. 


4-1 صيانة المنتج 


ما أن يصبح المنتج جاهزاً حتى يدخل في مرحلة الصيانة كجزء 
من دورة إنتاج المنتج. في هذه المرحلة» ينتقل التركيز من جودة 
المنتج إلى إرضاء العميل. ولا يمكن إجراء الكثير في ما يتعلق بجودة 
المنتج» إذ يتم في هذه المرحلة توزيعه في موقع العميل بوجود 
الأخطاء التي لم يتم اكتشافها بعد. فكيف يمكننا التأكد من أن العميل 
لا يشعر بعدم الرضا نتيجة هذه الأخطاء التي سوف يكتشفها ما أن 
يبدأ باستخدام المنتج؟ ففي حين تعتبر صيانة المنتج من الأمور التي 
لا بد من تطبيقها لأي منتج برمجيء. غير أن إصلاح العيوب 
الموجودة في منتج تم تطويره عن طريق عد مرودون في مراع 
مختلفة تعمل عن بعد بفاعلية وكفاءة تمثل تحديا. في هذا القسمء 
سوف نلقي نظرة على صيانة المنتج في مشاريع تطوير البرمجيات 
الموزّعة المراكز والحاجة إلى العلاقة طويلة الأمد مع المزودين في 
مؤاق 'التؤميطة الى تمل عن تعداوا لاتبتراويجيات: المتيعة لتعرير. مدل 
هذه العلاقات. 


1-4-1 صيانة المنتج في إطار شامل 
يتم الحكم على جودة صيانة المنتج عن طريق فاعلية وكفاءة 
(2003 ما يأتى : 
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- تراكم الإصلاحات: أصبح من الممكن قياس المعدل الذي يتم 

به إجراء إصلاح العيوب التي يتم الإبلاغ عنها. 

الوقت اللازم لإصلاح جميع الأخطاء من اللحظة العى يكم 

الإبلاغ عا اذ يمحن او يي تصستب العيوب ويتم قياس 

الوقت اللازم للاستجابة اعتمادا على مستويات العيوب. 

بحيث تاخذ وقتا أطول من الوقت اللازم للاستجابة. 

الصحيحة» أي الإصلاحات التي لا تقوم بتعديل العيوب أو 

تؤدي إلى عيوب جديدة. 

بالنظر إلى هذه المعايير» يتضح أن عملية الإصلاحات ستكون 

فعّالة وذات كفاءة اعتماداً على فاعلية وكفاءة الأشخاص الذين 
يقومون بها. وسوف تعتمد فاعلية وكفاءة الأشخاص الذين يقومون 
بالإصلاحات على مدى معرفتهم الوطيدة بالمنتج الذي يقومون 
بصيانته؛ ولا يوجد بديل لذلك. ومن الواضح أن الأشخاص ذوي 
المعرفة الوطيدة بالمنتج هم أنفسهم من قام ببرمجته. فلذلك يجب أن 
نرغم المزودين في المواقع التي تعمل عن بُعد على أن يقوموا بصيانة 
المنتج بالإضافة إلى جانب برمجته. ويجب أن نلاحظ أن انتساب 
المزودين للتنظيم المركزي الذي يمتلك المشروع قد يضيف بعداً آخر 
لعملية الصيانة. وسوف تختلف الطريقة التي يتم بها التعامل مع 
أعمال الصيانة عندما يكون كل من التنظيم المركزي والمزودين جزءاً 
من نفس الكيان قانونيين عن الطريقة التي تستخدم عندما يعملان في 
كيانين قانونيين مستقلين. وسنلقي مزيدا من الضوء على ذلك في 
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1-1-4-1 الحاجة إلى وجود علاقة عمل طويلة الأمد 

تمثل عملية بناء فريق عمل تحدياً كبيراً في بيئة العمل الموزّعة؛ 
إذ يتظلب ذلك جهدا كبيراً كالسقر لتعريف" أعضاء الفريق الداخلي 
بنظرائهم في الخارج وتكوين موقع وهمي مشترك للمشاركة في 
التغييرات وبناء الأنظمة الإدارية ومجتمعات التدريبات» حيث يستطيع 
أعضاء الفريق الحصول على أجوبة عن تساؤلاتهم. لذلك من المفيد 
المحافظة على علاقة مع الفرق الخارجية لمدة زمنية طويلة» وإن لم 
تفعل» فيجب أن تبذل الجهد الكبير نفسه فى كل مرة تجد فيها 
شريك عمل جديد. ْ 

ومع ذلك» كما ورد في الملاحظات الافتتاحية» يكون بناء 
تعاون طويل الأمد مع الفريق الخارجي أكثر أهمية للحصول على 
دعم مستمر وإجراء الإصلاحات على المنتج قيد البرمجة. 


يجب أن يتم التعامل مع الفرق الخارجية كامتداد لعمل الوحدة 
التجارية المركزية التي تمتلك المنتج. لذلك يقوم الفريق المركزي 
بوضع الخطط لبناء الموقع المختص ليكون مركزاً لأعمالهم بمرور 
الوقت. وهذا يعني أنه من المفيد تدريب الفريق الذي يعمل عن بعد 
على المدى البعيد للعمل التجاري. سوف تتحسن فاعلية التعاون مع 
مرور الوقت (2005 ,8]»155 320 1.35562). لذلك» سوف يتم لمس 
العوائد من التكلفة التي تم بذلها على مشروع التطوير الموزع بعد 
سنوات من العمل التعاوني» أو قد يُلمس ذلك في المشروع القادم, 
وليس في أول مشروع مع وجود مواقع جديدة. 


2-1-4-1 الاستراتيجيات المتّبعة لتعزيز العلاقات الودية 
هناك عدد من الطرق المتاحة لتطوير ععلاقات عمل جيدة مع 
المزودين الذين يعملون في المواقع التي تعمل عن بُعد» منها: 
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© الثقة: لن تنجح العلاقات طويلة الأمد من دون وجود ثقة 
متبادلة. فيجب أن يتم اكتساب الثقة التي تحتاج إلى وقت 
لبنائها؛ غير أنه يمكن اختصار الفترة الزمنية اللازمة لبناء الثقة 
عن طريق «الالتزام بعمل ما تقول». من المقترحات لذلك 
القيام بعمليات التسليم في المواعيد المحددة؛ إذ يجب أن يكون 
هناك التزام من كلا الطرفين» ويجب الالتزام بالجدول الزمني. 

© احترام الزملاء: كجزء من استراتيجية بناء مركز منافس يعمل 
عن بُعدء يجب أن يُعامل أفراد فريق العمل كزملاء ذوي قيمة 
ومحترمين. وهذا يختلف عن معاملة أفراد فريق العمل في 
الزقع الذي يحم قر جك كعدال لعملرة بعلت الم الضيرة 
فقط. ويؤدي هذا الاحترام إلى فائدة طويلة الأمد في بناء 
مهارات تقنية وخبراء في المجال من أفراد الفريق الذي يعمل 
عن بُعدء. هذا على افتراض أن العلاقة سوف تستمر لمدة 
طويلة. 

© تبادل أفراد فرق العمل : إن أفضل طريقة لنقل المعرفة وبناء الثقة 
بين التنظيمات هي جعل تبادل أفراد فرق العمل بين المواقع 
المختلفة. وللوصول إلى غايتنا في عملية تطوير البرمجيات 
المورّعة المراكزء نشجع انتقال أفراد فريق العمل الذي يعمل 
عن بُعد إلى الموقع المركزي للمشاركة في أنشطة المراحل 
الآولية. كما ننصح أن يعمل بعض أعضاء الفريق المركزي 
كمندوبين لفترات طويلة في موقع الفريق الذي يعمل عن بعد. 

© تخطيط الكفاءات وتطويرها: يجب وضع الخطط لأعضاء الفرق 
التي تعمل عن بُعد حتى ينمو لديهم حس المسؤولية بحيث 
يصبحون مركزاً تنافسياً. على سبيل المثال» في مشروع نظام 
إدارة المباني الآلي» تم التخطيط لأن يصبح مركز البرمجة في 
سلوفاكيا منافساً في مجال المعدات والتطبيقات لمشروع دائرة 
التلفزة الخاصة 0©01377). كانت البداية بتطوير نماذج العمل 
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وتطبيقات مشروع دائرة التلفزة الخاصة» غير أنهم أصبحوا 
خبراء تقنيين فى هذا المجال. 

© الحفاظ على تماسك فرق العمل: بما إن رعاية العلاقات أمر 
حتمي لتبقى طويلة الأمدء فمن المهم الحفاظ على الأعضاء 
المميزين لفريق الإنتاج معا. وحين تتحسن الظروف الاقتصادية 
فى الدول ذات المرتبات المتدنية» قد يتجه مهندسو البرمجيات 
إلى تغيير وظائفهم باستمرار لتحسين مرتباتهم. ويجب أن يحاول 
المزودون المحافظة على الفرق التي تعمل لديهم معاً لسنين 
عديدة لإجراء وتنفيذ مهام التطوير والصيانة. ويمكن أن يتم 
هذا عن طريق توفير عمل تمتع وطويل الأمد» وأيضاً توفير 
إغراءات مادية كوجود نظام حوافز لفترات طويلة (115:آ) أو 
مكافات دورية. 

© العمل التعاوني: العمل التعاوني الجيد ليس الأمر الوحيد الذي 
يجب توفره في فريق البرمجة» إذ يجب أن يكون هناك عمل 
تعاوني جيد بين الفرق التي تعمل عن بُعد والفرق المركزية 
لعمليات التطوير الموزّعة. قم باختيار فريق عمل يحقق تواصلاً 
أفضل بين أعضاء فريقه ويمتلك مهارات اجتماعية. ويمتلك 
بعض أعضاء فرق العمل موهبة «مهارات الربط»» كالتوفيق 
بين الخصوم وفهم الثقافات المختلفة والمهارات اللغوية» وغير 
ذلك. 

© التخطيط لفترة طويلة: شارك المزودين مخططك طويل الأمد. 
فعلى الرغم من أن بيئة العمل التجاري قابلة للتغيير» ما يعني 
ضرورة تغيير الخططء غير أنه لا بد من وجوب إعلام 
المزودين بعدد العاملين المطلوب والمهارات الضرورية وأي 
أمور أخرى تتعلق بالعمل بشكل عام. 

© التفاوض حول السعر: لا تقم بالضغط على المزودين مادياً حول 
سعر ساعة العمل» أو أي أسعار أخرى لتوفير مبلغ صغير من 
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المال. أوصينا في الفصل التاسع بأن يكون تقدير أجرة برمجة 
أي من أجزاء النظام بمعدل أكبر قيمة وأقل قيمة تقديرية يتم 
قبولها. وتكون أجور العمالة لدى المزود بحدود 20 بالمئة إلى 
0 بالمئة من أجرك. وقد يؤدي الضغط للحصول على خصم 
مقداره من خمسة بالمئة إلى عشرة بالمئة إضرار العلاقة مع المزود 
أكثر من الفائدة المحرزة من التوفير في النقود. 


فكرة مفيدة: 

قم بمراقبة الأشخاص المسؤولين عن المشتريات خلال 
فترة التفاوض حول العقد مع المزودين. 

يوجد عدد كبير من أعضاء فريق العمل ممن يمتلكون 
الحافز لتقليل التكاليف بنسب مئوية محددة من قيمة 
العقد. فى الكثير من الحالات» قد لا يدركون (أو لا 
بوكو الأعراف المتعلقة بالعقد الخاص بالمشروع أو 
العمل التجاري. قم بإقناع أعضاء فريق المشتريات أن 
التوفير في التكاليف لم يجدٍ شيئاً إذا لم ينجح البرنامج 


3-1-4-1 انتماء المزودين إلى المؤسسة المركزية 

عندما لا يكون المزودون جزءاً من نفس الكيان القانوني الذي 
ينتمي إليه التنظيم المركزي» من المرجح أن يكونوا جزءاً من 
وحدات تنظيمية أخرى ويمتلكوا أساساً مختلفاً أو شركات مستقلة. ما 
أن يتم إنهاء المشروع البرمجي» ينتقلون إلى مشروع آخر. في ظل 
هذه الظروف» من المهم أن يُوجد الفريق المركزي استراتيجية 
لتحديد الأولويات وتحديد التغييرات التى يطلبها العملاء عند تحديد 
الأعضاء المناسبين في التنظيم التقامن بالمرف قد يؤدي هذا إلى 
إشكالية. حيث إنه قد يكون لكل وحدة تنظيمية أهداف 
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وأهداف عمل قد تتعارض مع الوحدة الأخرى. إن الاستراتيجية 
مناقشته في القسم السابق» الهدف هو أن تتم معاملة المزود على أنه 
سيقدّم عملاً مستمراً وتقوم بتطويره بحيث يصبح مركزاً منافساً. 
لذلك» يجب على التنظيم المركزي أن يجعل المزودين جزءا من 
استراتيجية العمل المستقبلي لديهم. 

إذا كان المزودون عبارة عن كيانات قانونية مستقلة» يجب أن 
يحذر التنظيم المركزي من تغيّر الموظفين إذا كان المزود موجوداً في 
منطقة مضطربة. لاحظنا وجود معدل تغيّر عالٍ في موظفي الشركات 
التى توجد فى مدينة بانغالور فى الهند. قد تساعد الاستراتيجيات التى 
تم التطرق لها في القسم السابق في تقديم حوافز طويلة الأمد في 
مثل هذه الظروف. 
5-1 الملخص والاستنتاجات 

من المهم استخدام الممارسات المتعلقة بضمان الجودة 
للحصول على عوائد ناجحة في مشروع التطوير الموزع. يجب أن 
يشارك العاملون في مجال ضمان الجودة في الموقع المركزي 
زملاءهم في المواقع التي تعمل عن بُعد للمساعدة في التحكم 
وتحسين عمليات البرمجة. يتم منع ظهور مشاكل متعلقة بالجودة 
بشكل أفضل» ويجب أن يتم اكتشافها قبل تسليم البرامج للعميل. 
6-1 أسئلة للمناقشة 

1. ناقش بعض المعايير والاستراتيجيات المتبعة للحفاظ على 

العمليات وجودة المنتج في مجال تطوير البرمجيات المورّعة 
المراكز. 
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2 ماهو هدف المحافظة على علاقات ودية طويلة الأمد مع 
المزودين في المواقع التي تعمل عن بُعد؟ 

3. ماهو طول الفترة الزمنية المتوقعة واللازمة للفريق الذي يعمل 
عن يُعد للوصول إلى أفضل أداء؟ 

4. كيف يعمل خبير الجودة في الموقع المركزي مع الخبراء في 
المواقع التي تعمل عن بُعد؟ 


المراجع 
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دعم البنية التحتية في تطوير 
البرمجيات الموزّعة المراكز 


لقد حضرت للتو أولى الفرق الموزرّعة إلى مشروع الأستديو 
العالمي من أصل ست فرق» وكان زاك يحاول وضع أسيين لدعم 
البنية التحتية» لا تحقق المطالب التى تحتاجها التقنية والبنية الهندسية 
للمشروع وحسبء بل وأيضاً الطبيعة التي تنتشر بها جميع الفرق. 
وكان الأمر الأساس موضع الخلاف في الفريق المركزي الطريقة التي 
تمكنا من تسهيل التواصل بين الفرق وكيفية التأكد من توفر مهارات 
حديثة للمشروع في التنظيم. بعد الانتهاء من وضع إدارة لعملية إنشاء 
للتعامل مع أجزاء العمل البرمجي ودمجها على أساس المواقع 
المتعددة التي تقوم بالبرمجة. 


نلقى فى هذا الفصل الضوء على الاستراتيجيات والأدوات 
المستخدمة في إدارة البنية التحتية في بيئة تطوير البرمجيات المورّعة 
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المراكزء ويوفر دليل استخدام عملي للطريقة الأفضل التي يمكن بها 
إدارة ذلك. ونغطي في هذا الفصل تحديداً النواحي الآتية : 
1. المعايبر التي يتم من خلالها اختيار البنية التحتية في مجال عمل 
تطوير البرمجيات الموزّعة المراكز. 
2 البنية التحتية المطلوبة للاتصالات والتنسيق» وإدارة المعرفة» 
وإذارة عيلية تكرين البرمناتك. 
3 العمليات الستخدمة لتشهيل: استخداء الببية العحفية يشكل 
7" 


1-2 معايير اختيار البنية التحتية 


يعتبر التحضير لبنية تحتية تُلبّي حاجات المشروع لعمليات 
التطوير المورّعة من العوامل المهمة لنجاح المشروع جنباً إلى جنب 
مع الأنشطة الهندسية والتخطيطية. ويجب أن تدعم أدوات البنية 
التحتية سهولة الوصول والتعاون والتوافق وسير العمليات والمعرفة 
والتكامل. وقد لا تحقق الأدوات التقليدية هذه المتطلبات بشكل 
جيد؛: وإذاءتم التيبق يذلك في وقت متاخن».يؤدي: انتشار هذه 
الأدوات التقليدية وهجرة الكفاءات إلى هدر المال والوقت» وفى 
نهاية الأمر إلى عدم سير المشروع كما يجب (2005 ,08102و 0) . ١‏ 


1-1-2 القدرة على الوصول 
يجب أن تكون الأدوات متوفرة في جميع مواقع البرمجة. وذلك 
يعني أنه يجب أن تتوفر لدى أعضاء فريق المشروع في المواقع 
المختلفة الصلاحيات الملائمة. إضافة إلى ذلك» يجب معالجة أي 
مشاكل تتعلق بشبكة الربط. وقد يكون هناك تعارض بين المواقع 
اعتماداً على شبكة الربط» وقد يسبب ذلك صعوبة في تبادل 
المعلومات والتوصيل بين الشبكات. إذا كانت هذه الأدوات تعتمد 
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على شبكة الربطء يجب أن تدعم هذه الآدوات عملية التوصيل في 
بيئة شبكات مقيدة الصلاحيات. إذا كان النظام الذي يتم تطويره نظاماً 
موزعاًء فقد تتأثر الشبكات التي يحتاجها النظام. فيجب أن يقوم 
مسؤول تسيق البفية التكية يتؤثيق :ذلك ويوطل: تقريرا إلى التعنيين 
حول هذه الأمور. وقد يعنى ذلك أن بعض الأدوات قد لا تكون 
مؤهّلة للانتشار في المشاريع المورّعة» ولذلك لا يمكن استخدامها. 
وقد تحتاج الأدوات التي تدعم عملية الانتشار وشبكات الربط بشكل 
محدود إلى دراسة إمكانيتها (على سبيل المثال» الحلول المبنية على 
أساس شبكة الإنترنت» أو الآدوات التي تستخدم بروتوكول نقل 
النص التشعبي 1815118 يجب أن يقوم مسؤول تنسيق البنية التحتية 
بإجراء التعديلات المطلوبة على إعدادات الشبكة أو على تنفيذ البنية 
التحتية). 


2-1-2 التعاون والتوافق 

يجب أن تدعم الأدوات التعاون والتوافق وفقاً لطبيعة مجال 
التطبيق. ولا يشير التعاون بالضرورة إلى تعاون متزامن» ولكن يشير 
إلى تعاون غير متزامن أيضاًء وهو التعاون المطلوب بين الفرق 
الموزّعة جغرافياً في عدة دول يكون التوقيت فيها مختلفاً. ويشير 
مصطلح التوافق إلك "العادق الذي يمكن به أن تتعاون الفرق المختلفة 
فعلياً أو ضمنياً في إحدى المهام المطلوب إنجازها. ويمكن أن يكون 
دعم التوافق الضمني على هيئة تفعيل عمليات الدخول والدمج. 

يمكن أن يتم توفير هذه الوظائف عن طريق تعديل نظام التحكم 
ليصبح على شكل أدوات تعمل على أساس دمج النصوص أو 
بواسطة التطبيقات نفسها لتصبح على شكل أدوات دمج محلدة. 
يتطلب التحكم بعملية التزامن البحث في المهام أو الأجزاء الصغرى 
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منها بهدف إجراء التعديلات. تحتاج هذه الأنظمة عادة إلى أسلوب 
عمل باستخدام شبكة الإنترنت. يجب أن تكون أجزاء المهام التي يتم 
التعامل معها أصغر ما يمكن. ومن ثم يتم تجميعها إلى أجزاء أكبرء 
وذلك لتقليل احتمال وجود أي تعارض. ومن المهم أن تكون عملية 
دعم التعاون والتوافق ذات مستوى متقدم» نظراً إلى أنها تتحكم 
بسهولة الاستخدام» وبالتالي احتمالية وجود اعتماد كافٍ من قبل 
أعضاء الفريق. 


3-1-2 العمليات 

هناك أمران مهمان مرتبطان باختيار البنية التحتية» وهما المدى 
الذي تتحكم فيه الأدوات بتنفيذ عملية معينة أو أن يكون هناك 
تعريف مرن للعملية. لسوء الحظ.ء من الصعب إيجاد أداة تدعم كلا 
الأخريف: إذ كلينا فرت الآداة مرونة اكير كان من الضضثة رهن 
تنفيذ عملية بواسطة وسائل تقنية. فعادة ما تكون الأدوات التى توفر 
يمناقزية ومنلظة كيل النقية الستل اه يعني عدم عيدليات 
ومخططات سير عمل محددة» لذلك توفر القليل من المرونة. يجب 
على مدير المشروع ومنسق البنية التحتية أن يتخذا قراراً ببخصوص 
الأدوات التي يجب استخدامها وفقاً لطبيعة المشروع. في مجال 
مشاريع التطوير المورّعة» تفضّل الأدوات الأكثر مرونة أكثر من 
الأدوات المحددة» لأنها نادراً ما تكون مصممة من أجل مشاريع 
التطوير المورّعة. على كل حال» يؤدي اختيار أدوات مرنة إلى حاجة 
أكبر إلى أداء يدوي لفرض تنفيذ العمليات. 


4-1-2 المعرفة والتكامل 
يجب أن تدعم البنية التحتية المعرفة بالتواصل والمهام التقنية. 
على سبيل المثال» يمكن تدعيم المعرفة بتوفير أكبر قدر منها في 
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موقع واحد وربط المهام المختلفة بالموقع ليتمكن المستخدمون من 
استعراضها. عند استخدام الوثائق التقليدية» يصعب الرجوع إلى أي 
معلومات تتضمنها هذه الوثائق. ومن المفضل امتلاك القدرة على 
الوصول بشكل مباشر إلى أي جزء من أجزاء المعلومات؛ وذلك 
لأسباب تتعلق بالقدرة على التتبع. ويتوفر لدى الكثير من الباعة 
مجموعة من الأدوات المدمجة التي تتيح القدرة على التتبع وتصفح 
المعلومات. وتكمن المشكلة فى أن التكامل يكون محدوداً بتوقعات 
مزودي هذه الأدوات. لذلك» ع أن يتم إجراء عمليات شراء 
مناسبة» قد تكون بعض الأدوات مصنوعة بشكل أفضل وتدعم إجبار 
إجراء العمليات» وأخرى قد تكون أكثر مرونة وأكثر سهولة في 
دمجها مع النظام. ويجب أن يتم تنفيذ الأدوات بحذر ووفقا 
لاعتبارات صارمة تحددها متطلبات المشروع (2005 ,لممتقمطورء 0) 
بحيث تصبح استثماراً مستقبلياً طويل الأمد في البنية التحتية 


والأدوات. 


2-2 التواصل والتنسيق 


يسبب نقص البنية التحتية التي تدعم الحاجة إلى طرفي التواصل 
المتكاملين في مشاريع تطوير البرمجيات ضعفاً في قدرة المبرمجين 
والإداريين على العمل كفريق متماسك ,20158 لصه اعاوطرع]2) 
(2001 (التواصل الرسمي كتحديث حالة المشروع الحالية والمحادئات 
العابرة غير الرسمية بين أعضاء الفريق). وهناك يُعدان لهذه المشكلة 
على الأقل (2005 بممفصورون). أولا هناك مشاكل تتعلق بسياسات 
البنية القتعية الاتمالات واستجداحانها: ثانيا» اشع عطلياك لقان 
أنه من الصعب إعداد وتنفيذ البنية التحتية» حيث تكون عرضة للخطأ 
ويكتنفها الغموض وتؤدي إلى نقص في المعرفة. 
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تمثل كلتا المشكلتين تحدياً لمشاريع تطوير البرمجيات المورّعة 
المراكز. في المراحل المبكرة لتطوير البرمجيات» نحتاج إلى عمليات 
اتصال مكثّفة (1994 ,[.21 ]ه] :5زء). لكن من الصعب المحافظة على 
محادثات غير رسمية مستمرة بين أعضاء الفرق المورّعة بسبب بعد 
المسافة وأمور تتعلق بفارق التوقيت» ما يؤدي عادة إلى اختلال فى 
الأنشطة وقد يتطلب الأمر إعادة العمل. قد يكون هناك حاجة إلى 
إعادة التواصل» هذا سيؤدي إلى وجود ضغط إضافي عندما يضطر 
الفريق المركزي إلى أن يجيب عن نفس الاستفسارات. وتُستخدم 
أساليب وأجهزة مرئية مختلفة للاتصال بين أعضاء الفريق الواحد فى 
أوقات مختلفة» وبالتالي يُفقد التناسق في التواصل. ١‏ 

1-2-2 استراتيجية التواصل والتنسيق 


تتمثل الدوافع الرئيسة وراء إيجاد استراتيجية للتواصل والتنسيق 
في الرغبة في زيادة القدرة على الوصول إلى المعلومات من قبل 
أصحاب العمل بطريقة منضبطة وإنشاء بيئة للمشاركين بحيث يشارك 
جميع أصحاب العمل في عملية تبادل المعلومات. 

يجب أن يكون هناك آلية فعالة للتعامل مع نوعين من التواصل» 
معلومات عابرة (معلومات ذات تأثير محلي ومعلومات ذات تأثير 
قصير الأمد) ومعلومات مستمرة (المعلومات التي لها كأثبرا مهم 2 
الفرق المختلفة أو التي يجب أن يتم توثيقها ليكون بالإمكان الرجوع 
إليها فى ما بعد). وقد يكون البريد الإلكترونى طريقة مفيدة للحصول 
غلى المعاوبات العابرة» لأنه طريقة سريعة 0 السهل استخدامهاء 
لكنه لا يناسب المعلومات المستمرة بسبب عدة عوامل» إذ لا يمكن 
استخدامه في المعلومات الأساس» أو لضمان مستوى ثابت للحصول 
علج التعلوماك من قل أضهاب القمل أن السمان تور المعلوفات 
حين احتياجها. ولن يكون البريد الإلكتروني مصدر معلومات مثالياً 
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لاستعادة المعلومات بعد استقبالها بأيام أو أسابيع بسبب الضعف في 
البنية والتنظيم. ولتحقيق انخفاض ملحوظ في نفقات التواصل على 
المدى البعيد» يجب أن يكون هناك قدرة على الوصول للمعلومات 
دون الحاجة إلى اتصالات أو استعلامات معقدة. ومن المهم أن 
يكو" التواصل والوثاكق بواضحة وضبوحا تاماء وعلى أغضاء الفريق 
المركزي أن يلعبوا دور الميسّر لهذا بدلاً من دور أصحاب 
الصلاحيات المطلقة (2005 ,ممقصسد0) . 


2-2-2 البنية التحتية الخاصة بالتواصل والتنسيق 
يجب أن يتم تصميم البنية التحتية الخاصة بالتواصل والتنسيق 
بعناية بحيث تدعم الأهداف الأساس الموضوعة لهاء وهي سهولة 
الوصول والتعاون والتوافق ودعم إجراء العمليات والمعرفة والتكامل. 
يوق نقوم فى الأقسام الآتبة بوضت: البدية الشحتية التي أنبىثت 
جدارتها من خلال خبرتنا. 


1-2-2-2 قوائم عناوين البريد الإلكترونى 

يمكن أن يتم العمل على التواصل عن طريق البريد الإلكتروني 
الرسائل الإلكترونية لجميع الفرق والتأكد من وجود عناوين لجميع 
أعضاء الفرق. ويتيح استخدام قوائم عناوين البريد الإلكتروني أيضاً 
الفهرسة الآلية لهذه العناوين فى فهرس خاص.ء وبالتالى حفظ هذه 
العناوين. ويجب أن يتم نسخ جميع عناوين أعضاء الفريق المركزي 
في موقع أو لدى كل فريق (2005 ,مصهدمة:»6). يجب أن تتوفر أيضاً 
قوائم عناوين لدى الفريق المركزي» لأن ذلك يسهّل تفاعل فريق 
المصممين والرؤساء ذوي العلاقة بكل فريق. وبافتراض أن استخدام 
الرسائل الإلكترونية هو الأكثر شيوعاً للتواصل» فإن قوائم العناوين 
تساعد في تبسيط التعامل مع الرسائل الإلكترونية. 
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2-2-2-2 البنية التحتية المتعلقة بالاجتماعات الأسبوعية 


يجب أن يعقد الفريق المركزي اجتماعات إدارية أسبوعية مع 
استخدام مقاسم خاصة بالاجتماعات أو أجهزة محادثة متلفزة أو 
المحادثة الصوتية أو أجهزة ربط الحواسيب الخاصة بالأعضاء. تتيح 
مقاسم الاتصال التواصل مع عدة أعضاء موزعين» وفي نفس الوقت 
للقاعة التى يجري فيها الاجتماع للمشاركة فى المحادثة. كما إنها 
تمتلك خصائص أخرى مثل الحصول على محادثة واضحة من دون 
تشويش. ويمكن استخدام المحادثة المتلفزة في بداية الاجتماع مع 
المواقع التي تعمل عن بُعد وفي حالة الاجتماعات غير العادية التي 
تتطلب ذلك. ويمكن استخدام المحادثة الصوتية في حال عدم توفر 
هواتف داخل القاعات لدى الفريق الذي يعمل عن بُعد. ويجب ربط 
أجهزة الحاسوب للتأكد من أن كلا الطرفين (الفريق المركزي والفريق 
تم الإشارة لها خلال عملية التحضير لهذه الاجتماعات). 


فكرة مفيدة: 

أطلب من الفريق الذي يعمل عن بُعد تجهيز مجموعة 
من الأسئلة كتابيا قبل الاجتماع وإرسالها. 

عن طريق الطلب من الفريق الذي يعمل عن بُعد كتابة 
استفساراتهم وأسئلتهم وإرسالهاء يحرص الفريق المركزي 
على تزفين أفكاز.واجوية مصقة للفريق الذي يعمل عن بعد. 
ويتيح ذلك الفرصة للفريق المركزي للتفاعل الداخلي مع 
أعضاء الفريق الذي يعمل عن بُعد وإزالة أي غموض أو 
اختلافات مستقبلية. تساعد الإجابة عن الأسئلة 
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والاستفسارات في إزالة أي غموض ينتج عن الجدال في 
الاجتماع مع الفريق الذي يعمل عن بُعد والغموض الذي 
ينتج من الحاجة إلى تغيير أو تعديل. كما ستؤكد أن يكون 
أعضاء الفريق المركزي الذين لم يشاركوا في الاجتماع على 
معرفة بالأسئلة الموجهة ومستوعبين لإجاباتها. كما نوصي 
أن يتم إرسال جميع الأسئلة الجيدة وإجاباتها إلى مكان ما 
بحيث تستطيع جميع الفرق الوصول إليها. 


3-2-2-2 استخدام منتديات المناقشة للمباحثات التفاعلية 
والاستفسارات 


يستطيع أعضاء الفريق الذي يعمل عن بُعد التسجيل في منتديات 
المناقشة الخاصة بمواضيع مختلفة مترابطة كإحدى الطرق التى يمكن 
من خلالها الحصول على المعلومات من الفريق المركزي. وتضمن 
هذه المنتديات فهرسة الاستفسارات» واستخدامها متاح دائماً غير 
إلى استفسارات بعضهم بعضاً. وينتج من ذلك تخفيف ضغط العمل 
عن الفريق المركزي. يُظهر الشكل 1-12 لقطة لأحد منتديات 
المناقشة الخاصة بمشروع الأستديو العالمي؛ يمكنك الإطلاع على 
مزيد من التفاصيل حول هذا الموضوع في الفصل الرابع عشر من 
هذا الكتات. 


فكرة مفيدة: 
تأكد من استيعاب الفريق الذي يعمل عن بُعد 
للتعليمات. 
إن إحدى الطرق التى تساعد على ضمان أن الفريق الذي 
عمل عن تعد اق امتوعي: يشكا كام التعلينات أن 
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إجابات الأسئلة هي عن طريق جعلهم يعيدون بكلماتهم 
الخاصة الإجابات التي فهموها. ويمكن أن يتم هذا 
شفويأًء أو كتابياً عن طريق جعلهم يكتبون السؤال 
والإجابة خلال الاجتماع» أو إرسال السؤال والإجابة إلى 
منتديات المناقشة. إن الخيارين الأخيرين لهما ميزة أن 
التساؤلات وإجاباتها يمكن أن تصل إليها الفرق الأخرى 
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الشكل 1-12: منتدى مناقشة لمشروع الأستديو العالمي 


4-2-2-2 تتبع عيوب البرنامج وإدارة التغيير 

يجب توفير أدوات مناسبة لتتبع العيوب وإدارة التغيير كما هو 
الحال في منتديات المناقشة» إضافة إلى ضرورة وجود عمليات تدعم 
وتقوم بتتبع العيوب وإدارة التغيير (انظر الشكل 2-12). 
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من المهم ملاحظة أن جميع الإعدادات اللازمة للبنية التحتية 
التي نوقشت في هذا الفصل تقوم على أساس استخدام الأدوات ذات 
المصادر الوم (501116 دومه) (بعد إجراء بحث وتحليل حول 
المعايير التي تم وصفها سابقاً) لمشروع الأستديو العالمي» وذلك 
لتجنب أو التحايل على تحدي توفر المعلومات. 
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الشكل 2-12: برنامج لكشف أخطاء البرمجة (15اهة31) 


(*) ممارسات متبعة في عالم البرمجة وتطوير البرمجيات وهي تتيح الوصول إلى 
الأساسيات الأصلية لمنتج برمجي - مثل الشيفرة البرمجية. ومن الأمثلة عليها برنامج 
(5]62151ة) المخصص للاتصالات الهاتفية من خلال الإنترنت و20118[1 تتعاذلا5 1398 سناك) 
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3-2 إدارة المعرفة : تصميم البرمجيات والنماذج والتوثيق 

إن عدم وجود آلية فعّالة لمشاركة المعلومات وضعف صيانة 
تصميم البرمجيات وعملية التوثيق المرتبطة بها والتعاون في إنجاز 
المهام يؤدي إلى تفاقم الأمور المتعلقة بإدارة المعرفة بطريقة تسخر 
الإمكانيات الفعلية لمشاريع تطوير البرمجيات الموزّعة المراكز. وقد 
تؤدي بعض الأمور التقنية كذلك إلى تفاقم مشكلة إدارة المعلومات 
مثل التداخل في الشبكات وصيغ البيانات غير المتوافقة ووجود 
إصدارات مختلفة للأدوات فى المواقع 118 لطة اعاوط2ع1]) 
(2001. وثمة تحدٍ جديد يضاف إلى عملية إدارة المعرفة الفعالة ناتج 
من كون طبيعة معظم آليات التواصل غير متزامنة لأنها تسُبِّبُ تأخيراً 
في الأداء وغموضاً في الرسائل ووجود تكرارات وتقادم في عملية 
التواصل. ويؤدي هذا أيضاً إلى تكوّن نموذج ذهني لدى أعضاء 
المواقع التي تعمل عن بُعد مختلف عنه لدى الفريق المركزي» 
ويختلف أيضاً بين الأعضاء أنفسهم. وبالتالي تكون عملية تطبيق 
النظام مختلفة عمًا تم تصميمه. 


هناك ثمة ملاحظة مهمة جداً من واقع خبرتنا العملية تفيد بأن 
عدم وجود بنية تحتية في الموقع المركزي يقود المواقع الأخرى إلى 
تأسيس بنية تحتية خاصة بها. ولا يخفف إنشاء بنية تحتية معزولة من 
مشكلة إدارة المعرفة. على الفريق المركزي أن يقوم أيضاً بإعداد دليل 
عن أساسيات استخدام البنية التحتية بنجاح وإلزام العمل بهذا الدليل. 


1-3-2 اختيار البنية التحتية لإدارة المعرفة 


معنا :]1 0ك العجلاق بوالستاسات" الستعة كن إذازة المعدقة 
على بناء قاعدة معلومات تتسناوك ويتعاون فيها الجميع. ويجب أن 
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تتكون قاعدة المعرفة من جميع المعلومات المتعلقة بالمشروع» مثل 
وثائق المهام التقنية والمهام الإدارية والعمليات والممارسات والبنية 
التحتية» وغير ذلك. يجب أن يدرك أصحاب المشروع حقيقة أن 
الإنشاء المجرد للوثائق ليس ذا قيمة بحد ذاته» لكنه وسيلة لتزويد 
جميع الأعضاء بالمعلومات التي يحتاجونها. 


لذلك يجب أن تعمل السياسات على تحفيز التواصل غير 
المباشر بحيث يصبح استخدام قاعدة المعرفة كوسيلة اتصال مباشرة 
تركز على الأهداف ذات المدى القصير والمفيدة في المجال الحالي 
أمراً مفضلاً. ولرفع مستوى المعرفة» يجب أن توفر قاعدة المعرفة 
آليّةَ ذكيةٌ لوضع الملاحظات بحيث يطلع المهتمون على آخر 
التعديلات أولاً بأول. كما يجب أن يتم إنشاؤها بشكل منطقي بحيث 
توفْر سهولة في التنقل وتجميع المعلومات المتعلقة بعضها ببعض في 
حقول معينة. 

إن وجود قاعدة المعرفة لا يلغي الحاجة إلى اتصالات مباشرة 
بالطبع. ومع ذلك». يجب أن يكون الفريق المركزي حريصاً على 
مراقبة عدم توظيف التواصل المباشر كبديل لأنشطة التوثيق. وسوف 
يعمل التواصل المباشر كآلية للأنشطة المتعلقة بالتنسيق فى عملية 
إنشاء قاعدة المعرفة الخاصة بالمشروع. على سبيل المثال» إذا 
ظهرت أي أمور أو أسئلة خلال الاجتماعات الأسبوعية أو 
الاجتماعات غير المخطط لهاء يجب أن يكون ذلك حول البند قيد 
البحث من قبل الفريق المركزي أو الفريق الذي يعمل عن بُعدى 
وبالتالي يجب أن يظهر في قاعدة المعرفة. ويجب على الفريق 
المركزي أن يراقب المعلومات ويلتزم بصيانتها الفريق الذي يعمل عن 
بعك. 


يجب أن تُجزأ قاعدة المعرفة إلى أقسام عامة أو شاملة» وأقسام 
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شبه عامة أو أقسام لفريق محدد. وبذلك يمكن المحافظة على 
الاستمرارية والتناسق والوضوح على الرغم من السماح للفرق 
بالمشاركات الداخلية باستخدام نفس الآلية التي نُستخدم في الشركات 
العامة. ويجب عدم التهاون مع الأقسام المنفصلة لأنها لا تؤدّي إلى 
الشفافية في المعلومات بل تحرم الفرق الأخرى من الوصول إلى هذه 
المعلومات» وبالتالي الحد من المعرفة. وبما إنه قد يلزم المشروع 
استخدام وثائق مهيكلة وأخرى شبه مهيكلة» لذا يجب استخدام تقنيات 
وأدوات مختلفة لأداء ذلك. بشكل عام» يجب أن يؤخذ بعين الاعتبار 
أنه من المفيد الاحتفاظ بأكبر قدر من المعلومات مركزياً باستخدام أداة 
واحدة لتحسين القدرة على الوصول إلى المعلومات. إن توفير 
معلومات عامة عن مهام المشروع الرئيسة للمهتمين بالمشروع من شأنه 
دعم التنسيق ويوفر التوجيه والإرشاد للفريق» وبالتالي توفير تعريف 
شبه رسمي لطبيعة المنتج المتوقع إنتاجه. يجب أن ينصبّ التركيز 
الأكبر للفريق المركزي على الالتزام بسياسات وعمليات التواصل 
خصوصاً في مرحلة التأسيس. يجب أن توكل مهمة إدارة التوثيق إلى 
عضو واحد في كل فريق يعمل عن بُعد ويعيّن مسؤولاً عن التطبيق 
المقبول للسياسات والعمليات المتعلقة. وبسبب التأخير فى التواصل 
غير الاش :وغور االسد اس كان عدن سد المماكل لودو قو 
وفي مثل هذه الحالات» يجب استخدام البريد الإلكتروني أو 
المحادثات الهاتفية (2005 ,مطهحطديء0) . 


نلخصٌ فى ما يأتى النواحى المهمة فى إدارة المعرفة التى يجب 
أخذها بعين الاعتبار عند إنشاء البنية التحتية في مشاريع تطوير 
البرمجيات المورّعة المراكز: 
1. إنشاء قاعدة معرفة مركزية ومتماسكة وتوفير أكبر قدر ممكن 
من المعلومات فيها. 
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2 إنشاء عمليات اتصال غير مباشرة وإلزام الأعضاء 
4. استحداث وظيفة مدير توثيق في كل فريق يكون مسؤولاً عن 
الحفاظ على بنية قاعدة المعرفة. 
2-3-2 البنية التحتية لإدارة المعرفة 
إن المحور الأساسى للبنية التحتية لعملية إدارة المعرفة هو 
مفهوم قاعدة المعلومات؛ كما ذكرنا سابقا. تحتاج متطلبات هذه 
القاعدة للمعلومات تطبيقا تم إنشاؤه اعتمادا على شبكة الإنترنت» 
خصوصا أنها يجب أن تدعم التوفر المستمر في بيئة شبكات مقيدة 
وتدعم أيضاً التعاون والتزامن. الفائدة من هذا التطبيق أنه يُسهّل عملية 
نشر المعلومات» والقدرة على الوصول إلى المعلومات باستخدام 
المتصفحات الشائعة» ويتيح إمكانية الاستخدام في أي مكان عن 
طريق بروتوكول نقل النص التشعبي (81118) المتوفر في جميع أنظمة 
الشبكات. تظهر التعديلات التي تُجرى على مصادر المعلومات 
الموجودة في الإنترنت فوراً لجميع المهتمين بالمشروع؛ ويمكن 
الوصول إلى إحدى المهام عن طريق اختصار شائع واحد (في حال 
وجود 2378/7/77 فإن هذا الاختصار هو عنوان الموقع الإلكتروني 
على الإنترنت 0081”). إن ما يقيد ذلك هو أن المعلومات تكون 
متوفرة إذا كان المستخدم متصلاً بشبكة الإنترنت فقط. أحياناً» يكون 
سير العمل غير مرض لدى تطبيقه باستخدام أدوات تعمل من خلال 
شبكة الإنترنت» ولا تتوفر أدوات مناسبة لجميع المهام التي تتطلب 
الأدوات التى تعمل من خلال شبكة الإنترنت فى أدوات تقليدية 
خاصة بالأجهزة التابعة فقط أو خاصة بالأجهزة التابعة والخادمة. 
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ومن أدوات إدارة المحتويات البسيطة التى اكتسبت شعبية مؤحراً 
ما يعرف بال 8111”*". وتوفّر هذه الأدوات أنظمة تتيح معالجة 
صفحات الإنترنت بشكل فوري في نافذة المتصفح عن طريق توظيف 
جمل برمجية خاصة يمكن استخدامها وتعلمُها بسهولة. هذه الأدوات 
مناسبة للوثائق شبه المنتظمة. إذ يمكن إنشاء وثائق جديدة بسهولة؛ 
كما يمكن الإشارة إلى الوثائق المتوفرة في أدوات ال 17/114 باستخدام 
جمل برمجية خاصة» أما الوثائق الموجودة في صفحات أخرى خارج 
نطاق ال 111 فيمكن الإشارة إليها عن طريق عنوان الموقع 
الإلكتروني على الإنترنت ب (1781). يمكن تضمين الصور وأي أمور 
أخرى داخل هذه الصفحات. 

على الرغم من أن خيارات التصميم والإعدادات ليست غنية 
كما هى فى الأدوات التقليدية» تكون إمكانيات إنشاء وثائق تقنية 
فعالة جداً في ال 7811. وليس بالضرورة أن تكون الوثائق متسلسلةً 
بدقة» ولكن يمكن تجزثتها إلى أجزاء منطقية بحيث يتم حفظها 
إلى أجزاء أصغر ويمكن تتبعها والوصول إليها عن طريق إعادة جمع 
هذه الأجزاء. 


خاصية التصدير في هذه الأدوات واستخلاص عروض لصفحة 
الإنترنت من الوثائق. عند توظيف نظام تحكم عمليات المراجعة. 


() ال 1814 هو موقع إلكتروني يسمح بإنشاء وتعديل أي عدد من الصفحات 
الإلكترونية المترابطة من خلال متصفح إنترنت» وذلك باستخدام لغة ترميز أو أداة تحرير 
نصوص من نوع ما تراه هو ما تحصل عليه «2478/9/5153/9706. ومن الأمثلة على المواقع التي 
تبنى باستخدام ال 18/314 الصفحات الشخصية المخصصة للتدوين ونظم إدارة المعرفة. 
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يُسمح بالدخول عن طريق الإنترنت إلى الأجزاء التي يتم التحكم 
بهاء ويمكن إضافة هذه الصفحات إلى نظام المراجعة ويتم الإشارة 
إليها عن طريق الوثائق الأساس التي تم الاحتفاظ بها في أداة 
ال 18ة378. كما قد يكون من الممكن الإشارة إلى المهام عن طريق 
ال 18/314 من الوثائق التي تم إنشاؤها بواسطة هذه الأدوات. وإذا لم 
يتم ذلك» يتم إنشاء جميع الوثائق عن طريق أدوات معينة وإنشاء 
بعض المهام المحددة التي تدعم الوثائق المكتوبة (مثل مخططات 
النماذج). وقد يتم تصدير هذه المهام (على هيئة صور مثلا)» ومن 
ثم يتم تضمينها في الوظائف. أما مساوئ هذه الطريقة فتتمثل في 
الحفاظ على القدرة على التتبع والتماسك يدوياً: ومن ناخية أخرى» 
تنشأ هذه الحاجة بشكل متكرر إذا لم تكن الأدوات المختلفة 
المستعملة متكاملة مع بعضها بعضا. 


إن استخدام التطبيقات المرتبطة بالإنترنت يتيح مركزة الآدوات 
المستخدمة» وتبقى هناك إمكانية لتوفير قدرة عالية للوصول إلى 
المعلومات. لهذه الخاصية تأثيرات إيجابية على إمكانيات التشاركية 
العى توقرهنا الأدؤات..ونظرا إلى هدم توقز قواعد نبانات موزّغة 
تكون عملية المشاركة مبسطة» ويتم عرض التعديلات فوراً على 
المهتمين من دون الحاجة إلى إجراءات متخصصة ومتزامنة. 


تم تطبيق أدوات ال 18/11 بنجاح في دراسة حالة مشروع 
الأستديو العالمي» ويتم توفيرها عن طريق قرص ضوئي مدمج. وقد 
كان باستطاعة الفريق المركزي تجهيز مشروع تطوير البرمجيات 
المورّعة المراكز باستخدام أدوات ال 18/114 في معظم عمليات التوثيق 
بشكل أفضل. أما المهام الرئيسة التي تم إجراؤها عن طريق أدوات ال 
أعلةللا فهي المتطلبات (حالات الاستخدام والنماذج ونماذج الشاشات) 
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والهيكلية (عروض مختلفة بمستويات مختلفة من التفاصيل)») والوثائق 
المتعلقة بالتصميم وخطة المشروع (الفرق والوظائف والتنظيمات 
والأدوات والبنية التحتية» وغير ذلك) والبرنامج الزمني ومجالات 
التعاون. تتيح صفحات المناقشة لكل صفحة 18/1 المحافظة على 
الأسس المنطقية للقرارات التي يتم اتخاذهاء كما تتيح خاصية إرسال 
الإشعارات زيادة الإدراك حول الأمر. تم مؤخرا تفعيل المناقشات 
المباشرة في منتدى المناقشة. تم دعم عمليات التتبع بواسطة أداة 
خاصة. كما تم تزويد الفرق بالقوالب الرئيسة لبعض الأنشطة الخاصة 
بالمنتج. وقد اهتم الفريق المركزي بشكل خاص بعملية صيانة هيكلية 
المعلومات والقدرة على الوصول إليهاء ومن ثم تطبيق أدوات ال 
7 لتعمل كقاعدة معلومات مركزية. واحتفظ الفريق المركزي 
بتسجيلات مرئية للاجتماعات المهمة تشمل تسجيلات لمحتويات 
الشاشات التي تم توفيرها من خلال أدوات ال 1ة18. وقد تم 
استخدام التسجيلات المرئية للمتطلبات والهيكلية كمرجعية 
للاجتماعات. على سبيل المثال» تم تزويد الفرق بها لفهم المتطلبات 
ومنطقية التصميم وسياق العمل بصورة أفضل. واستّخدمت تسجيلات 
محتويات الشاشة كبديل للدليل المكتوب عن عمليات التنصيب 
والتطبيق. ويمكن استخدام تسجيلات محتويات الشاشة المدعومة 
بالصوت لتخيّل المهام التقنية بصورة أفضل؛ على سبيل المثال» 
عندما تمت مناقشة اللغة الموحدة لتشكيل النماذج شفويا. 


تختلف الحاجة للاتصالات والتوثيق وإدارة المعرفة من مشروع 
لاخر وفقا لطبيعة المشروع. سوف تختلف طبيعة الوثائق» فقد يتم 
إنشاؤها بصورة رسمية أو عادية وفق المنهجية المستخدمة. عادةً ما 
تكون قاعدة بيانات المتطلبات رسميَّةَ في المشاريع الكبيرة؛ كما 
تكون أكثر: تنظيما :وتكون عمليابة: إدازة الاعداذانت أكثن حقة: لا بوبحل 
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توصيات محددة حول البنية التحتية لإدارة المعرفة لأنها تعتمد بشكل 
كبير على متطلبات المشروع والخيارات المتاحة. بشكل عام» يجب 
أن تكون الأدوات البسيطة مفضلة على الأدوات التى تتطلب عمليات 
محددة وهيكلية خاصة لتوفر المرونة وسهولة الاستخدام. 


4-2 إدارة إعداد البرمجيات 


تعرف إدارة إعداد البرمجيات بأنها إدارة الطريقة التي يتم بها 
إنشاء البرمجيات وتعديلها من خلال نظام التحكم بالشيفرة البرمجية 
المصدرية (0006 ع5801116)» والتحكم بالمراجعة» وتتبع إنشاء 
الكائنات البرمجية وبناء الإصدار البرمجي عندما تصبح جاهزة. 
ويتضمن ذلك تحديد إعدادات البرمجية عند نقطة زمنية معينة 
والتحكم المنظم بالتغييرات التي تطرأ على الإعدادات وضمان أن 
تكون الإعدادات قابلة للتتبع بشكل مستمرء وأن لا تواجه أي مشكلة 
في عمليات التوافق خلال فترة عمل المشروع ,[له اع] عللنتةط) 
(1993. 


تلعب إدارة إعداد البرمجيات دوراً محورياً في نجاح أي مشروع 
برمجي. تشير خبرتنا أنه عند زيادة الضغط على مشروع التطوير 
البرمجي» يتم التخلي عادة عن العمليات» خصوصاً تلك التي تُتَقَذَ 
في الشركات المبتدئة قليلة الخبرة» وأول ما يتم التخلي عنه العملية 
التي تتحكم في إدارة واستخدام البنية التحتية لإدارة إعداد البرمجيات. 


إتسع نطاق الإعدادات البرمجية عبر السنين لتشمل إدارة إعداد 
المهام وليس فقط البرمجيات. ولذلك» يجب أن تتم إدارة هذا 
النشاط بفاعلية منذ بداية مشروع التطوير البرمجي ولا ينتهي بانتهائه» 
ولكن يستمر حتى انتهاء جميع أجزاء البرمجية. 
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1-4-2 اختيار البنية التحتية لإدارة إعداد البرمجيات 


في إدارة إعداد البرمجيات في مشاريع تطوير البرمجيات 
الموزّعة المراكزء من المهم أن يستلم أي عضو من أعضاء الفريق 
جميع المعلومات المتعلقة بالعمل الذي يقوم به أعضاء الفريق 
الآخرون وكيفية سير العمل في المشروع والوضع الحالي للمشروع 
والتغييرات التي تم تنفيذها والعضو الذي قام بهاء وغير ذلك. عند 
التعاون فى برمجة نفس الشيفرة البرمجية المصدرية فى العمليات 
الجررعة المراكف يجب ضمان وجود آلية نقل اتسككرة وطزانة حك 
الطلب) لآن المبرمجين يحتاجون إلى الإطلاع على التغييرات التي 
يجريها كل منهم (1999 ,[.1ه اع] لمسكامهة) . 

من المهم أيضاً دعم القدرة على مشاركة الملفات والتغييرات 
المتزامنة. أما الحلول التي تتضمن استخدام خاصية «الإغلاق» 
والسماح بدخول الأشخاص المصرّح لهم إلى الملفات فيجب أن 
تعمل بفاعلية وكفاءة نظراً إلى صعوبة التعامل مع الوضع عندما يكون 
أعضاء الفريق موجودين في مواقع مختلفة ويضطرون إلى انتظار 
بعضهم بعضاً. ويجب أن يتم كل هذا بالطبع من خلال شبكات 
متعددة (وغير منفصلة) من أجل دمج العمل في المواقع المختلفة. 

2-4-2 البنية التحتية لإدارة إعداد البرمجيات 

في مشروع الأستديو العالمي» استُخدمت في البداية أداة لإدارة 
إعداد البرمجيات لم تكن مناسبة للتطوير الموزع من خلال الشبكات 
العامة والشبكات متوسطة السرعة؛ وقد كان ذلك متوقعاً وفقا 
لخبرتناء وأيضاً وفقاً للمعلومات الموثقة حول هذا الموضوع. وحين 
الانتقال إلى مرحلة التطبيق المتقدمة في المشروع حيث يعمل على 
المشروع عدة فرق موزّعة» أدرك الفريق المركزي أهمية البنية التحتية 
لإدارة إعداد البرمجيات» وقرروا الانتقال إلى نظام تحكم معدل يتيح 
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القدرة على الوصول إلى المعلومات باستخدام بروتوكول نقل النص 
التشعبى الاعتيادي» وبالتالى اكتساب القدرة على الدخول حتى في 
نظام الشبكات المقيدة. يتم استخدام برنامج خاص لربط البرمجة 
بنظام المصدر المفتوح لتحقيق التكامل بين لغة ال منلنةة 01ناكل؟ 
(نظام التطوير المدمج الذي ثم اختياره بشكل مبدئي) والبرنامج 
المعدل الذي يتم استخدامه. ولكن التجارب أظهرت أن ذلك غير 
قابل للتطبيق خلال عمليات الإنتاج. وهناك ثمة أمور أخرى تتعلق 
بالاستخدام المزدوج لنظام التحكم الذي تم تعديله ولغة ال 7151181" 
هذلدةة» لكن الفريق المركزي كان قادرا على التغلب عليها. 

1-2-4-2 إدارة التكامل والوحدات المبرمجة 

تُعتبر عملية تنسيق تطوير البرمجيات المورّعة المراكز من عوامل 
تنظيمات البرمجيات التعاونية وإدارتها. وفي بيئة العمل التي يوجد 
فيها عدد من الأشخاص وعدة قواعد عمل» يتم توفير آراء 
وانطباعات وملاحظات فورية للمبرمجين في ما يتعلق بقبول الشيفرة 
البرمجية الجديدة» كما يقومون بتسهيل جمع العمل المنجز للأجزاء 
المختلفة أو المتمائلة من المشروع. إن إنشاء الوحدات المبرمجة يومياً 
بالاعتماد على النسخة البرمجية الأخيرة كل مرة من شأنها تعويض 
الإخفاقات التقنية وتختبر البرمجيات الجديدة وتحدد المشاكل 
المحتملة وتعرض النتائج بشكل فوري على المبرمجين الموزعين في 
مؤسسات ودول مختلفة (2003 ,201205لا) . 


(:#) الوحدة المبرمجة هي جزء من البرمجية قابل للتركيب والعمل بما تتضمنه من مزايا 
وخصائص. ونُستخدم لتركيب البرمجية لأغراض الفحص والاختبار غالباً. ويمكن الحصول 
على هذه الوحدات البرمجية أوتوماتيكياً باستخدام أدوات معينة كأداة أصهة عطعدمة . 
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هناك تشكيلة واسعة من الأدوات ذات المصادر المفتوحة التى 
يمكن استخدامها في عمليات البرمجة والدمج. ومن أمثلتها أداة إعداد 
الوحدات المبرمجة (:ههل<)» والأداة (10م[201) التي تُستخدم في 
اختبار الوحدات البرمجية وعمليات الدمج. أما بالنسبة إلى الأداة 
(251).» فيقوم البرنامج (:101.18:1 م ع5 نط ) بدمج (أسكاح) 
و(0نهنال2) والنظام الذي تم تعديله معاًء وبالتالي يمكن استخدام تلك 
الأدوات بفاعلية لعمليات الدمج المستمرة ,اعتصتحدعه لصة تعانتده2) 
(2005» إذ إنها مفيدة فى الاختبار وإنشاء الوحدات المبرمجة 
أوتوماتيكياً. وهذا يعني أن المبرمج يقوم في كل مرة بتسليم الشيفرة 
البرمجية التي كتبها وتضمينها في النظام. وتقوم الأداة باختبار تلك 
الشيفرة البرمجية على النسخة الأخيرة من النظام. يتم ترجمة نتائج 
هذه البرمجة والاختبارات المتعلقة بها على شكل سجلات لوصف 
الحالات وتسجيل الأخطاء»؛ ويمكن الوصول إلى هذه السجلات 
بسهولة باستخدام تطبيقات بسيطة من خلال الإنترنت تكون بمثابة 
نافذة للدخول إلى المشروع. بالتالي» يتمكن جميع المبرمجون من 
الحصول على بيانات الوضع الحالي للدمج والاختبارات والوصول 
إليها بسهولة. ويمكن الحصول على ميزة أخرى باستخدام أداة 
(#صحلا) وهى عملية الإنشاء التلقائى للوثائق المتعلقة ببئية برمجة 
التطبيقات (421) التي يتم توفيرها في الموقع الإلكتروني أيضاًء 
بحيث يكون الوصول إليها سهاا. 


3-4-2 إدارة إعداد البرمجحيات لسهيل التطوير البرمحى 
الشامل 
لن تحقق البنية التحتية لإدارة التهيئة (24©) أهدافها من دون 
اقترانها بعملية مُعَدَّة ومنفذة بشكل جيد. وتشمل عملية دعم إدارة 
التهيئة ما يأتي: (1) تحديد «رسمي» للأمور التي تطبق عليها (نموذج 
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العملية)» و(2) الآلية التي يتم تأكيد العملية بشكل فعلي من خلالها 
(2000 ,عناطناة). وقد لوحظ أيضاً أن دعم العملية الأفضل والأكثر 
مرونة هي الخاصية التي تفتقدها معظم أدوات إدارة التهيئة» وذلك 
لأن جميع أنظمة إدارة التهيئة تعتمد على دورة حياة المنتج المعدة 
مسبقا وغير المرنة (2000 ,عناطناو8) . 


نظراً إلى الجهود المبذولة لتوزيع مشروع التطوير البرمجي في 
المناطق الجغرافية المتعددة. ظهرت الحاجة إلى وجود عمليات 
برمجة متزامنة في جميع المجالات بما في ذلك مخطط التنفيذ. 
ويمكن القيام بتغييرات متعددة على نفس المهمة أو على عدة مهام 
مختلفة قبل توزيع الوحدات الجزئية لأحد الأنظمة البرمجية على 
المتاظق: المختلفة .وعتملهنا يشكال مترامرة. 


يمكن للمبرمجين الذين يُطلب منهم العمل في فروع برمجة 
مختلفة ومتوازية العمل فى بيئات برمجية معزولة (*«32060) بغض 
النظر هن الطبيحة الجانية لتعدل »رمد تيون استحد ام خيرات 
أخرى مؤقتة. على كل حال» يؤدي العمل بشكل منعزل إلى عدم 
معرفة المبرمجين بما يقوم به كل منهم». وبالتالي يكون هناك احتمالية 
أن يقوم بعضهم بإجراء تغييرات لا تتوافق مع عمل بعضهم بعضاً. 
يجب أن يتم حل هذه المشاكل حين دمج هذه الفروع في فرع واحد 
ل 

يمكن القيام بعملية البرمجة المتزامنة بعدة مستويات. على 
مستوى النظامء يتم تطوير المنتجات الفرعية أو الوظائف المختلفة 
بشكل متواز مع بعضها (تطوير متزامن للنظام)؛ وفي مستوى أدنى 
أكثر تفصيلاًء يمكن أن يقوم عدد من المبرمجين بإجراء تغييرات 
متزامنة على عدة إصدارات لنفس الملف (برمجة متزامنة للبرنامج). 
كلما كان مستوى البرمجة أقل» كان إجراء عمل متزامن ممكنا بشكل 
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أكبر. ولكن تكون المخاطر أكبر من وجود عدم توافق في التغييرات. 


أولأء تؤدي الهيكلية المتماسكة للمنتج (بئنية تصميمية) إلى 
إتاحة جعل الروابط أكثر وضوحاً وتجزيء العمل إلى عدة أقسام يتم 
العمل عليها. كلما كانت الأجزاء غير مترابطة ولا تعتمد على بعضها 
بعضاً. كان من الأسهل وصف علاقاتهاء وكان احتمال وجود 
تعارض بينها قليلاً. حينها يكون توزيع المسؤوليات المتعلقة بالأجزاء 
المختلفة للمنتج على الأفراد المبرمجين أو على مجموعات العمل 


ثانياً. إن وجود مستوى مرتفع من الإدراك للعمل الذي تم 
إنجازه والعمل قيد الإنجاز حالياً من قبل المبرمجين الآخرين أو 
مجموعات المشروع الأخرى يساعد في تقليل مخاطر وجود تعارض. 
إن البرمجة المتزامنة التي تتم في مستويات بسيطة أكثر تفصيلا تتطلب 
إدراكاً أكبر من البرمجة التي تتم في مراحل متقدمة. في العمل 
المتزامن على مستوى النظام» قد تكون معرفة إذا ما تم تغيير 
العلاقات وفي أي وقت تم تغييرها أمرأ كافيا؛ لكن عندما يعمل 
مبرمجان اثنان على نفس الوحدة» فإنهما يحتاجان على الأرجح إلى 
معرفة إذا ما كان الطرف الآخر قد بدأ العمل فى نفس الملف ومتى 
بدأ ذلك. ْ 

1-3-4-2 المهام المحددة بدقة 

تنشأ المهام المحددة بدقة نتيجة الإدراك المتزايد بأن هناك من 
يعلم بما يقوم به الآخرون. وهي من الأمور المهمة التي تتعلق 
بالتعاون الذي يتم بين فرق العمل عبر مسافات كبيرة. كما إنها تقلل 
خطر حصول سوء فهم (نتيجة اختلافات ثقافية على سبيل المثال). 
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لكن ذلك لا يحقق إدراكاً حقيقياً في دعم النظام» أي لا يوضح 
الأحداث التى حدثت في الماضي أو تلك التي تحخدث الآن. فعن 
طريق تحديد مهام كل عضو من أعضاء فريق التطوير لن يقوم أي 
منهم بالتقليل من أهمية العمل المتزامن عند مستويات العمل 
المنخفضة. 


2-3-4-2 المسؤوليات الحصرية 

سكس اددول لسعو سان دست 0 لانت كيف الففانة 
مجموعة من الملفات أو الوحدات) من التقنيات الشائعة الأخرى. 
خصوصاً عند وجود مشروع برمجي جديد» وهذا يكون ممكناً عن 
طريق إنشاء هيكلية مناسبة للمنتج» وتقسيم العمل بين المبرمجين 
بحيث يصبح كل منهم مسؤولاً عن أجزاء مختلفة من المنتج. وينتج 
من وجود مهام واضحة وعلاقات محددة عمل جيدء خصوصاً بين 
المواقع التي تعمل بشكل منفصل. وعلى الرغم من ذلك» فإن 
الإدراك من الأمور المهمة» فلذا تجد بعض مشاريع تطوير البرمجيات 
الموزّعة المراكز تبحث عن روابط أفضل بين المبرمجين في المواقع 
المختلفة تتيح إمكانية تبادل العمل يوميا وليس خلال الاجتماعات 
الأسبوعية فقط. وذلك لأنه من الممكن أن يقوم شخص واحد فقط 
بإجراء تغييرات على أحد الملفات كنتيجة لتقسيم المسؤوليات» ومن 
النادر استخدام الفروع الجزئية على مستوى الملفات. 

من الصعب إجراء تقسيم للمسؤوليات بنفس الطريقة خلال 
عمليات الصيانة. فبدلا من تجزثئة المهام المتعلقة بالصيانة إلى مهام 
صغيرة جدأء يجب أن ينفذها أشخاص مختلفون وفق مجالات 
مسؤولياتهم؛ من الأفضل أن نمكن المبرمج الذي لاحظ وجود خطأ 
بسيط في وحدة العمل لدى مبرمج آخر (قد تكون الوحدة ضمن 
فروع عمله) أن يقوم بتعديل فوري لهذا الخطأء ولو مؤقتاًء ويقوم 
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بعدها باختبار التغييرات التي قام بها. وهذا أمر مهم جداً خصوصاً 
عندما يوجد المبرمجون في مواقع مختلفة (على الرغم من أن الوجود 
في المواقع المختلفة يصعب من تنفيذ ذلك). يجب حينها إبلاغ 
المسؤول عن الوحدة أن شخصا آخر قام بإجراء تعديل مقترح على 
وحدتهء ليقرر عندئذ إذا ما كان يجب دمج هذا التعديل في الفرع 
الرئيس للعمل. 


إذا كان عدد أجزاء المسؤوليات التي تم تقسيمها أكبر من 
اللازم» تصبح مسؤولية كل مبرمج محدودة جذا حيبت #يكؤن 
المبرمجون مقيدين في مجال العمل. يعتقد بعضهم أن أسلوب العمل 
الخاص بمشروع التطوير الجديد الذي نتحدث عنه ينتج فقط من عدم 
وجود دعم كافٍ لعمليات التطوير المورّعة» وهذا من الأسباب التي 
تدعو إلى الحصول على إدارة التهيئة أكثر بساطة من دون وجود 
فروع عمل. بدلاً من ذلك. يجب أن يُتبع أسلوب العمل الطبيعي 
بحيث يطبّق كل وظيفة جديدة شخص مسؤولء وهو الشخص نفسه 
الذي يقوم بتطبيق الملف الذي تم إجراء التغييرات عليه كاملاً. ومن 
الواجب أيضاً القول إن الصيانة وعمليات البرمجة الإضافية لمنتج 
ناجح هي من أهم المراحل التي يمر بها المشروع (يشكل ذلك وفقاً 
لبعض المصادر حوالى ثمانين بالمئة من المشروع). لذلك» وعلى 
الرغم من أن الاهتمام بإجراء عمليات الإنشاء للأدوات والعمليات 
لمشروع برمجي جديد أمر شائع أكثر من الاهتمام بالصيانة وعمليات 
البرمجة الإضافية» غير أن ذلك يُعتبر خطأ كبيراً وفقاً لما تم بحثه. 


فكدرة مقهدة + عقن القارافد الاجر اند لآذازة إعيناد 
البرمجيات (1999 ,31.1 غة] 0منكاده) : 
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أن المعلومات متزامنة وحديثة» ويفضل أداء ذلك تلقائياً 
باستخدام أداة تدعم ذلك. 

تطوين متزامتة» خصوصا إذا كانت: الحماية تقيل عمل 
يجب دمج الفروع المؤقتة في ما بعد مع الفروع الأصلية 
في أقرب زمن ممكن والتخلص من الفروع المؤقتة. 
شي طفي اسمن ندال الجاكلية اسه لمعا عه إلى 
الفروع. وإذا تم الاستمرار في استخدام الفروع. تقلل 
الهيكلية الجيدة من مخاطر عدم التوافق عند إجراء أي 
4. لا تقم بتجزيء العمل إلى جركياك صضغيرة جذا 
وحدات محددة» إذ إن ذلك يؤدي ل الجمود وعدم 
عدة تغييرات تؤثر فى الملف نفسه بشكل متزامن» 
بالتحديد إذا كانت التغييرات المختلفة قد تؤثر فى 
المسؤوليات فى المناطق المختلفة. 


5-2ا١‏ لملخص والاستنتاجات 


المورّعة المراكن هي المواضل والعشاوة» :واذارة المتغيرفة + و إدارة 


203 


الفعال» يجب التركيز على القدرة على الوصول إلى المعلومات من 
قبّل جميع المهتمين بالمشروع وعلى إنشاء بيئة تشاركية بحيث يساهم 
جميع الأفراد في المشاركة في المعلومات. إن مبداً وجود قاعدة 
معرفة هو محور البنية التحتية لإدارة المعرفة. في الحقيقة» يجب آلا 
تتكون قاعدة المعرفة من أداة واحدة بل قد تتكون من مجموعة من 
الأدوات المتكاملة جيداً (2005 ,قتصهددة”مء6). طالما أن إدارة إعدادات 
البرمجية أمر مهم. فقد لاحظ إستبلييه (2000 ,#عناطدمة8) أن الدعم 
الأفضل والأكثر مرونة للعملية هو من أكثر الخصائص التى تفتقدها 
أدوات إدارة التهيئة» لأن معظم هذه الأدوات تعتمد على عدا داتياء 
وبالتالي تفتقد إلى المرونة خلال تعاملها مع المنتج. 

وهذا ما يجعل إدارة إعداد البرمجيات في مشاريع تطوير 
البرمجيات المورّعة المراكز أكثر تحدياً. وكما إن هدف التقنية توفير 
احتياجات الأعمال التجارية» فلن تحقق البنية التحتية لإدارة التهيئة 
أهدافها دون تضمينها مع عملية مخَطْطٍ لها بشكل جيد ومنقّذة أيضاً 
بشكل جيد. ويعدٌ الحد من اعتماد المبرمجين على بعضهم بعضاً من 
الاستراتيجيات الناجحة في أي عملية برمجة.» خصوصا إذا كانوا 
يوجدون في أكثر من موقع. ويمكن تنفيذ هذا بشكل رئيس خلال 
عملية إنشاء هيكلية (الهيكلية) المنتج المراد تطويره. ويتم تقسيم 
النظام إلى وحدات أو أجزاءء ومن ثم تبرمجها مجموعات مختلفة 
وبشكل منفصل. على كل حالء اتضح أنه وعلى الرغم من وجود 
هيكلية جيدة» غير أن العلاقات تدوم بين المكوّنات. يتضح هذا حين 
ظهور الحاجة إلى تعديل الروابط أو حين الحاجة إلى دمج 
المكوّنات. هذه بعض الأمثلة على حالات يحتاج فيها المرء (على 
الرغم من أنه حاول تجنب ذلك) إلى الإطلاع على عمل مجموعة 
تعمل على مكوّنات مختلفة وإيجاد تزامن بين أعمالهم 6ه] لصناكاده) 


(1999 ,[.له 
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6-2 أسئلة للمناقشة 
1. ماهي الركائز الثلاث لإعداد بنية تحتية في مشاريع التطوير 
المورّعة؟ 
2 متى يجب إنشاء البنية التحتية لمشاريع التطوير الموزّعة؟ وما هي 
الفترة التي يجب أن تستمر فيها؟ 
3. في مجال مشاريع التطوير المورّعة» هل تدعم أداة مخحططات 


التنفيذ (84©) سير العمل بشكل أفضل أم الأداة التي تساعد 


المراجع 


ئءك1200ك/ 


22 .215501 .لثم 3210 ,212821155082 .8 ,.لآ ,0 تتاعاوم 
-© 7102 أل 411011 "لاع 2011[7) 07110 106121021116111 :1ن 0 ]50 10151711110 
.9 ,1021715169 تنمآ نطعلع51 ,لقتال «.امرعدم 


- 801111001165 620114117118 7/» .اعمع 1715 122 لصهة 111115 ,ناعهتلاء1' 
(. 7115© 1 126110721116111 © "زبلا ظاةا 507 171 110710227116111 011011 "1لهج 2011/7 
ول[ع010ططعع 1" 01 01171517نآ تتمعالا :112أونتث ,رقصمع 1م 


10 0 0 


علة 5017 210112.5010601 5012عمء26آ1 امه [2١‏ وعصمول ,طعاوطمع1] 
/حاعتة 1/1 16-20 ,2 .20 ,18 .701 :ع هناد 0ك ناطظ[1 «.أصعمدمماءرعد[1 
مم 


و501]57731:6 101 1أع1100 8420117 '«اللتطومهةن» .[.21 أع] 11211 ,علانوط 
.3 ,5181-93-115-024 /1110ن) «.1 .1 اماومع/؟ 


رع1ممع8» .1018 .6) .آ 220 ,لعل 2تطمع51210 على .!8 ,.8 .(آ بلإترعط 
50/107 1ط 11 «. ا اعطاء1017م حم[ ووعء210 220 ,221005 1موع 01 
.36-5 .مم ,1994 أنتاعنتث /إ1نال ,4 .20 ,11 .1701 


101 5ل1تنا8ظ لإلتطعالط 01 جمعاوتزك 4181005 .عل موععاى ,20105 لآ 
بذن) ,معع016آ هك ,2003 طط شن «.أمعصطمماء7ه10 موادا 
2003 
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كع عل 6011/6 


-020] لل :] عطتطعع 11212 51113110 00011) ع:5015701» .لإكاعة[ ,اعلا طناوظط 
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(لفصل الثالكت عشر 
التواضل 


كانت شركة متعدّدّة الخنسيات 5071 تعمل في “مشترروع تطوير 
برمجيات موزّعة منذ ستة شهور عندما اكتشفت أن شبكة معمَّدَةٌ جداً 
من عمليات المشروع قد سيطرت على ستة مواقع مختلفة للشركة 
حول العالم. جاء بعض المهندسين في بعض المواقع للتعرف على 
نظرائهم في مواقع أخرىء ما أدى إلى ظهور عدد لا يحصى من 
قنوات التواصل بينهم. في العادة» يقوم هؤلاء المهندسون بإيصال 
احتياجاتهم. ويتفقون على ما يتم تسليمه مؤقتاء وأنشأوا وتبادلوا 
المنتجات البرمجية لي ومن ناحية 
أخرىء كان هناك مهندسون في بعض بعض المواقع معزولون» كار من 
يتواصلون مع نظرائهم الذين يعملون عن بُعد. ما أدى إلى ضعف 
فهم العمل المخصص لهم وعدم تناسقه واتصافه بالغموض. 

تقع على عاتق شركة (©8128) الآن مهمة شاقة وهي تنظيم 
استخدام قنوات التواصل. فحين ترك التواصل من دون تحكم أو 
سيطرة» سيكون هناك عدد كبير جداً من حالات التواصل ما يؤدي 
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إلى وجود ضغط كبير غير مبرر وشبكة معقدة من العمليات قيد 
العمل؛ ويؤدي وجود عدد قليل جداً من قنوات التواصل إلى نقص 
ف تادل السلوهات: وضطه المشاركة نى العم فلاتوضمل الدربى :نما 
هي الوضاولة افيد لاللة كنع بكي أن كفل الح متعددة 
السيات هن ال 


سوف نسلّط في هذا الفصل الضوء على أدوات التحكم 
والعوائق المفروضة على التواصل في مشاريع تطوير البرمجيات 
الموزّعة المراكز. وسيؤدي فهم ذلك إلى استيعاب أكبر لاستراتيجيات 
التطوير اللازمة للتعامل الفعّال مع التواصل بين الفرق المورّعة وتنظيم 
فعال للأنشطة التي يقومون بها أيضاً. وقد تم أيضاً مناقشة التقنية التي 
يمكن استخدامها لتتبع التواصل بين الفرق الموزّعة في عدة مواقع 
لإظهار العلاقات بين روابط الهيكلية للمشروع. تتطلب الروابط 
الميقة والحردة الات مكسة »وعدم العفنية تساعد المديوية ف 
تحديد أنواع الروابط المهمة وتعزيز التواصل المكثف بين لقوق 
المتعاونة. 


1-3 أدوات التحكم بالتواصل 


تمل علاقات الترابط بين المهام ووجود روابط في التنظيم - 
وفقاً لخبرتنا ووفقاً للنظريات الموجودة ‏ عاملاً محفزاً مهما لنقل 
المعلومات بين الفرق المتعاونة (2002 ,[.21 ]»] 5052). كلما كان 
مستوى علاقات الترابط كبيراً بين المهام. كانت الحاجة للاتصالات 
أكبر؛ وتزداد هذه الحاجة بشكل أكبر إذا تخلل هذا التواصل شعور 
بعدم التأكد والغموض. في هذه الظروفء» تتفاعل الفرق المتعاونة من 
اجل : 
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© الحد من الغموض: لمواجهة المعلومات غير الدقيقة والحد من 
تأثيرهاء يجب الحد من الغموض وتحويله إلى مجموعة من 
المسائل المحددة جيداً أو الوصول إلى اتفاق لحلها. 
© الحصول على الحد الأعلى من الثبات: عند وجود نقص في 
الالوماك في تادلالغلوفاف الام اشرحية الحانا تكون 
متوفرة) وذلك لمعالجة هذا العيب. 
إن وجود روابط في التنظيم تجعل الأعضاء المنتمين إلى نفس 
الفريق يشعرون بهوية واحدة تربط بينهم. كما تؤدي هذه الروابط إلى 
وجود اتصالاات مستمرة بشكل أكبر في ما بينهم لشعورهم باللاختللاف 
عن أعضاء الفرق الأخرى. 


تحقق أدوات التحكم هذه هدفاً أكبر :في مشاريغ تظوير 
البرمجيات المورّعة المراكزء إذ إن تنفيذها من قبل أعضاء ينتمون 
إلى متظنات مورّعة فى مناطق حخرافية مختلفة يمثل تحدياً لعمليات 


العنيق السك 


فكرة مفيدة: 

قم بالحد من روابط المهام. 

يجب : يحدد المموريره المهام ذات العلاقات 
تقذها الفرق العو رع قطنا ملق 00 
لا ترتبط بروابط تنظيمية مع بعضها (على سبيل المثال» 
البرمجيات» بخاصة في مراحل التخطيط. إجراء 
الوا ا وسوف تؤديا المسافة الكبيرة 00 
5 
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فكرة مفيدة: 

قم بتسهيل التواصل بين الفرق التي تعمل على مهام 
مترابطة. 

عند وجود روابط حرجة للمهمةء. يجب أن يقوم 
المسؤولون بتسهيل التواصل المكثف بين الفرق 
المضطلعة بالعمل على هذه المهام. وقد يتطلب التغلب 
على المسافة الكبيرة بين الفرق وعدم معرفة أعضاء 
الفريق بعضهم بعضاً إيجاد روابط قوية في ما بينهم. 


2-3 عوائق التواصل 


لقد وجدنا أن العوامل الآتية تعيق تبادل المعلومات بين فرق 
البرمجة عندما تتواصل مع بعضها (2002 ,21.[1 أع] 5058) : 


© بعد المسافة: تؤثر المسافة سلبياً فى التواصل. يكون عامل 
المسافة مهما عندما تتجاوز خمسين مترا؛ فعندما تزيد المسافة 
على ذلك يصبح هناك انبيار حاد في التواصل» ولن يكون 
هناك فرق إذا ما كانت الفرق المتعاونة تقع في مبنيين 
تختلفين أو.هديتتين أو.ذولتين أو حتى قارتين ,مع1آه) 
(1984. 

© تداخل أوقات العمل: تقل احتمالية وجود اتصالات متزامنة 
بين الفرق المترابطة عندما تقل الفترات التى يتداخل فيها 
العمل .نين امو اقم !اللخولقة تويكو احتمال. التواصل ٠وعهاً‏ 
لوجه منخفضاً جداً؛ يتم استخدام الهاتف للتواصل بين 
الفرق التي يوجد بينها فترات تداخل في أوقات العمل» 
والبريد الإلكتروني هو الطريقة المفضلة في حال عدم وجود 
أي تداخل في أوقات العمل. 
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فكرة مفيدة: 

إذا كان ممكناء تجنب المواقع التي تعمل عن بُعد 
ذات الفارق الكبير في التوقيت عن الموقع المركزي. 
الصعوبة التي تواجهها المواقع المركزية في أميركا 
والصين هو وجود فارق كبير في التوقيت بينهما. وهذا 
يقلل من إمكانية وجود اتصالات هاتفية عفوية. حتى 
عندما يتم وضع مواعيد زمنية للمؤتمرات كالاجتماع 
التحضيري اليومي». فمن المرجّح أن يكون على الأقل 
تزويد مقره في شرق الولايات الكمشجودة يقوم 
بالتواصل مع الفريق الذي يعمل لديه الموجود في 
الهند قبل أن يخلد إلى النوم ليلا. ويقوم بالتواصل 
بينما كان هو نائماً. وحين ظهور مشاكل في العمل» 
يكون تجنب هذه الفروقات الكبيرة في التوقيت أمراً 
غير ممكن لأسباب تتعلق في العمل التجاري 
والتسويقي. فعندما تواجه وضعاً مماثلاء حاول 
تخصيص مجموعات عمل للموقع الذي يعمل عن بعد 
بنية تنظيمية» بحيث يتم تحرير مع إحدى المواقع 
الأخرى بواسطة الأقمار الصناعية (على سبيل المثال» 
الربط مع إحدى المواقع الأوروبية التي ستتقاطع أوقات 
العمل فيها مع كل من المنطقة الشرقية في الولايات 
المتحدة ومع الهند أيضا). 
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© الاختلافات الثقافية واللغوية: ثمة نزعة طبيعية لدى البشر تتمثل 
في البحث عن المشابهين لهم للتواصل معهم. لذلك» تكون 
فرص التواصل أكبر بين فريقي عمل إذا كانت الفروق الثقافية 
واللغوية ما بينهم قليلة. أما وسائل التواصل المفضلة عند 
وجود اختلافات ثقافية ولغوية كبيرة بين الفرق المتعاونة فهى 
الوسائل الكتابية كالبريد الإلكتروني. ١‏ 


فكرة مفيدة: 

قم بتسهيل وسائل التواصل الكتابية غير المتزامنة. 
يجب أن يقوم المسؤولون بتسهيل وسائل التواصل 
الكتابية غير المتزامنة بين الفرق المتعاونة التى يكون 
بينها الختلاف كبير فى اللغة. وهذا يساعد أعضاء 
الفريق على تنمية العلاقات التواصلية التى تلعب دوراً 
مهماً في حصول الشخص على المعلومات وتعلّم كيفية 
أداء العمل وإيجاد حلول للمهام الذهنية المعقدة. وقد 
أظهرت الأبحاث أن الوثائق ذات قيمة أقل فى 
الحصول على المعلومات» في تخي يحصل مهندلسو 
البرمجيات على معلوماتهم من الآخرين حطة أسدمك]) 
(1995 ,هاءها5. لذاء ما من بديل يغني عن العلاقات 
الشخصية. 


© الدافع التنظيمي والثقة: في مشاريع تطوير البريجيات الموزّعة 
المراكز التى تشتمل على منتجات ستحل مكان الأنظمة 
القديمة» تكو التنظيمات التي تدعم الأنظمة القديمة أقل 
ثقة بالشركاء على الأرجح» وذلك لأنهم ينظرون إلى الآمر 
كتهديد لأمنهم الوظيفي. ومن المرجح أيضاً أن تكون هذه 
التنظيمات أقل دافعية وحماسة للمشاركة في المشاريع الجديدة. 
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© العلاقات الشخصية: هناك احتمالية ضعيفة للتواصل بين أعضاء 
الفرق المتعاونة ما لم يتعرف أعضاء هذه الفرق على بعضهم 

في مشاريع تطوير البرمجيات المورّعة المراكزء وبوجود فوارق 

فى التوقيت بين الفرق» ناهيك بوجود اختلاف كبير فى الثقافة 
واللغة» تكون العمليات الإدارية التى تجرى على هذه الفرق صعبة 


من ناحية التنظيم والتحكم. 


فكرة مفيدة: 
كن على دراية بعادات العمل الموسمية في مواقع 
البرمجة. 


سوف تكون فترات العمل في المواقع الموجودة في 
أميركا الشمالية» فى الأغلب» مشابهة لفترات العمل فى 
أميركا الجنوبية. ولكن» قد تكون المواسم معكوسة. ما 
يعني عدم توافق فترات العطلات بين الفرق» أو الفترات 
التي تكون فيها إنتاجية العمل مرتفعة أو منخفضة. ضع 
خطة برنامج العمل الزمني وفقاً لذلك. ليس من المرجح 
أن يكون هناك إنتاجية عالية في آخر أسبوع من شهر 
كانون الأول/ ديسمبر في معظم بلاد العالم. 


3-3 التواصل والتنسيق 

من المعروف أن التواصل يلعب دوراً مهماً في تحسين أداء 
تطوير المنتج (2002 ,[21 »] 5058)» وتحديداً على تحسين أداء الفرق 
المتعاونة» وبخاصة عندما تكون المهام مترابطةً ,#عاءه5 لمة غسم]) 
(1994 بدماأة0201 لصة عدواأة21 :1995. ومع ذلك» وكما تم ذكره 
سابقاًء يمكن أن يكون تنسيق الأنشطة المترابطة التى تتطلب عملية 
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اتصالات مكثفة صعباً في مشاريع تطوير البرمجيات الموزرّعة المراكز. 
يمكن تحسير: التواصل وَالَتَنْسِية عن طريق تطبيق المبادئ الثلاثة 
الآتية والمستمدة من النظرية التنظيمية ,5عط21128© 0صة 'إعموعط0ء31) 
2004. 


1. نظرية التنسيق: نصّت النظرية على أن التنسيق هو عملية 
لإدارة العلاقات الترابطية بين الأنشطة. يمكن استخدام مبادئ 
نظرية التنسيق لتحديد علاقات الترابط التنسيقية وآليات 
التنسيق اللازمة لإدارة هذه العلاقات. وفى ما يأق بعض 
الأمئلة على علاقات الترابط التنسيقية وآليات التنسيق: ' 

أ) توابع المصادر المشتركة» مثل وحدة البرمجة» يمكن 
التعامل معها من خلال أداة إدارة التهيئة. 

ب) روابط قيود المتطلبات السابقة» كأن يتم الموافقة على 
طلب إجراء تغيير قبل أن يتم توكيل أحد مهندسي 
البرمجيات بإجرائه» ويمكن التعامل معه عن طريق 
استخدام الإجراءات المتعلقة بإدارة التغيير. 

ج) روابط إمكانية الوصولء. كإيصال معلومات عن إجراء 
تغيير موافق عليه إلى أحد مهندسي البريجيات» ويمكن 
التعامل معه عن طريق نظام تحديد تلقائي أو يدوي 
للمهام. 

د) روابط إمكانية الاستخدامء كالحاجة إلى المواصفات 
الكاملة لطلب التغيير» ويمكن التعامل معه عن طريق 
النموذج الموحد لطلبات التغيير ووضعه حيز التنفيذ آلياً. 

ه) روابط ذات قيود مطابقة» كإنشاء الوحدات المبريحجة يومياًء 
ويمكن التعامل معه عن طريق استخدام إجراء الوحدات 
المبرمجة المعياري وعن طريق إدارة إعداد البرمجيات. 
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و) روابط المهام والمهام الفرعية» كتجزئة مهام المشروع إلى 
مهام جزئية لتسهيل إدارة المهام المعقدة» ويمكن التعامل 
معها عن طريق هيكلية عمليات تجزئة العمل واستخدام 
تقنيات التخطيط ك 08821 و]برص 2*0 

أساليب التواصل: وهى أساليب يستخدمها عادةً أحد أعضاء 

جتجع .ما للؤضول إل عفن الأخداننفى ممع البرعنات» 

على سبيل المثال» تُستخدم المقابلات والاجتماعات في مراحل 

ختلفة خلال فترة عملية التطوير البربجى وذلك للموافقة على 
الهام قد البحت أو إبداء الرأئ جولهاه 

العقل الجماعي: إن وجود فهم مشترك من الأمور الأساسية 

لنجاح أي مشروع» لأنما تعكس مدى فهم الفرق المتعاونة 

للمسألة التي تقوم بمحاولة حلها. السؤال الذي يتبادر للذهن 
في هذا السياق» «هل يركزون في الاتجاه الصحيح للوصول 
إلى الهدف العام؟». وتنص نظرية العقل الجماعي على أنه يتم 
تعزيز الفهم المشترك من خلال التفاعل بين أعضاء الفرق 
التعاونية» ومن الصعب الرصرة إل عد بق مر 
الوزعة بحخراداً عل منالان تداقة: ' 


إن آليات التنسيق المستقاة من نظرية التنسيق وأساليب التواصل 


هي الآليات الرسمية للتواصل» بينما يمكن إيجاد العقل الجماعي من 
خلال تبادل المعلومات. ووفقاً لخبرتناء ووفقاً للنظريات القائمة» فإن 
آليات التواصل الرسمية مفضّلةٌ في المهام الروتينية وتكون أكثر فعالية 
عندما تكون المشاريع محددة وواضحة؛ ويلعب التواصل غير 


(8) عناوتصطاءء1' ااعتوع1 220 ممنمة 81211 مسوععوهءط (2)6811. وهى تقنية تستخدم 
لإدارة المشاريع مصممة لتحليل وعرض اللمهام التي يجب إنجازها لإكمال المشروع» خصوصاً 
الزمن 0 لإكمال كل مهمة وتحديد أقل وقت ممكن لإنهاء المشروع كاملا. 


) انظر: 4-2-5 تحديد المسارات الحرجة. 
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الرسمي دوراً مهمأ في مواجهة عدم التأكد ووجود نقص في 
المعلومات (1995 ,7عاءة]5 220 ]نل 2ك1) . 


لسوء الحظء تتعامل معظم عمليات تطوير البرمجيات مع مسائل 

ل ل ل ل 
للتغيير في أي وقت. التحدي في التطوير الموزع. وفقاً لذلك» هو 
قن امووان ,داف لها لتر فد وهات ب اع وملنات 0 
الشخصية وغير الرسمية. هذا النوع من التواصل مهم جداً في 
المراحل الأولية من عمليات التطوير البرمجي» أي عندما تكون في 
طور التحليل. من المهم أن يمتلك جميع المشاركين فهماً عاماً لهذه 
رت ل إيجاد الحلول لها. وما إن 

يتم إنهاء مرحلتي البدء والتطويرء حتى تصبح المعلومات أكثر ثباتاً 
0 تأكيداً» وتقل الحاجة إلى اتصالات غير رسمية مكتّفة. 


فكرة مفيدة: 

كوّن فهماً مشتركاً بر بين الفرق العاملة في المشروع. 

يمكن أن يشارك عفاد ع الفرق التي تعمل عن بعد الفريق 
المركزي خلال مراحل البدء والتطوير التي يتم أثناءها 
بعد انتهاء مرحلة التطوير» يكم إعادة بعصي أعتماء الفرق 
التي تعمل عن بعد إلى مواقعهم الأصلية» ليتم اعتبارهم 
خبراء في هذه المواقع, ويقوموا بخلق فهم مشترك 
ا ل ا 8 
المركزي بالسفر بشكل منتظم إلى المواة د 
بُعد لمشاركة أعضاء هذه المواقع في استخدام النظام 
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الذي يقوموق بجنائه كما :هو كدعئ هذه النقنية أحاناً 
«استخدم منتجك». عن طريق التدريب على الواقع 
الحقيقي الذي سوف يُستخدم فيه النظام» وسوف يكوّن 
لفريق الذي يعمل عن بُعد إدراكاً ومعرفة أفضل للمسألة 
لتي قاموا بحلها. 

إن عملية تبادل الأعضاء بين الموقع المركزي والمواقع 
لتى تعمل عن بُعد مفيدة أيضاً لتفاعل الأعضاء وجهاً 
لتحددوس عن عاض كاد مسو فانم رشن الجفارت 


4-3 التواصل والتحكم 


على الرغم من أن التواصل الفعال والتنسيق أمران مهمان جداً 
لتحسين آداء المنتج» يكون التواصل الزائد ضارًا. وإذا لم يتم التحكم 
بالتواصل» سوف يكون هناك قنوات كثيرة من التواصل بين الفرق 
المتعاونة» ما يؤدي إلى إنشاء شبكة معقدة من العمليات التى تجري 
مسن المفروع ».يمك أن يودي :ذلك أيقدا إلى وجوه صحظ كبر 
على تناقل المعلومات وقد يتم نقل معلومات ليست ذات أهمية» 
وبالتالي صرف الانتباه عن المعلومات المهمة المتعلقة بالمشروع. 
فضلاً عن أن التواصل قد يكون مكلفاً مادياً مثل التواصل الدولى 
وتكلفة الرحلات والتنقلات التي تنم لتحقيق التواصل. ْ 


من الاستراتيجيات المتبعة لتعزيز التواصل بأسلوب مسيطر 
عليه» تقليل روابط المهام المورّعة وتسهيل عمليات التفاعل في ما 
يتعلق بالمهام المترابطة بشكل كبير بين الفرق المتعاونة. وللوصول 
إلى هذاء يجب امتلاك القدرة على تتبع قنوات التواصل بين الفرق 
المختلفة للتأكد من أن الفرق التي تعمل على المهام المترابطة تتفاعل 
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بشكل جيد. ويصف القسم 1-4-3 تقنية يتم اتباعها للقيام بهذا 
التتبع؛ ويسمى ذلك «تحليل الشبكات الاجتماعية»» إذ بدأت 
مجتمعات مهندسى البرمجيات بالاهتمام بهذه التقنية. 


1-4-3 تحليل الشبكات الاجتماعية 

إن عملية تحليل الشبكات الاجتماعية (5214) هى عملية مبنية 
على تقنية المسح لإظهار التفاعلات المتبادلة بين الفرق أو الأفراد 
(1991 ,560]1). ويتم إنشاء رسم بياني يسمى (50610873:0) للعلاقات 
الاجتماعية بناءً على الإجابات التي تم الحصول عليها من استبيانات 
ركؤتث على الطريقة التى يتواضل الثاسس بها ومدئ فاغلية هذا 
التواصل. يمكن أن ف مز الرسوم البيانية العلاقات بشكل مرئي» 
ويمكن من خلالها استعراض أنماط عمليات التواصل والتغيرات التى 
حصي لك عجن انا سو جة رهن لاك لبقا الت قطري فيه ورد 
تواصل فكت بعوضن 'الشكل 3 1 جقالا على ذلك. 


أوروبا 


الشكل 1-13: أنماط التواصل بين فرق عمل في ثلاثة مواقع مختلفة 
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تمثل نقاط التقاطع في هذا الرسم البياني الأفراد» وتمثل 
الأطراف مسارات التواصل. تم رسم دوائر حول التجمعات للتظليل 
المرئي حول المناطق التي تعبر عن اتصالات مكثفة. ويعرض الرسم 
البياني للعلاقات الاجتماعية في الشكل 1-13 عدة نواح مثيرة 
للانتباه» منها: 5 


© الفريق الموجود في الولايات المتحدة مندمج بشكل أفضل من 
الفرق الموجودة في أوروبا وآسيا؛ ذلك يعني أن جميع أعضاء 
فريق الولايات المتحدة يتفاعلون مع بعضهم البعض. 

© بعض أعضاء الفرق الموجودة في آسيا وأوروبا منعزلون ولا 
يتفاعلون مع معظم أعضاء فريقهم؛ وهذه الفرق هي '2” 
ولط في الفريق الموجودة في أوروباء والفريق ”5 في الفريق 
الموجود في اسيا. 

© الفريق الموجود في آسيا مجزأ؛ فعلياًء هناك مجموعتان جزئيتان» 
الأولى تتضمن ”0 و'5” و 00 و80”. والثانية تتضمن '0” 
و”1” و'ل” و'0”. ويمكن اعتبار العضو "0” حلقة وصل بين 
المجموعتين الجزئيتين. 

© هناك تفاعل محدود بين الفرق الثلاث؛ ومحدود جداً بين الفريق 
الموجود في أوروبا والفريق الموجود في آسيا. 

© يُعتبر العضو 00 في الفريق الموجود في أوروبا حلقة الوصل 
بين جميع الفرق» لأن جميع عمليات التواصل بين الفريق 
الموجود في أوروبا والفرق الأخرى تمر من خلاله. 

© إذا ترك العضو 65 الفريق الموجود في أوروباء يفقد هذا الفريق 
تواصله مع الفريقين الآخرين. 

قد لا تكون هذه الملاحظات سيئة بالضرورة وذلك وفقاً للمهام 

المتعلقة بالمشروع وطريقة تخصيص المهام والفرق. على كل حال» 
عندما تكون عمليات التعاون والمشاركة في المعلومات حرجة ومهمة 
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لنجاح المشروع» توفر عملية تحليل الشبكات الاجتماعية (5814) أداة 
تحليلية قوية لاستخدامها من قبل المديرين. ويمكن أن تساعد عملية 
تحليل الشبكات الاجتماعية (5214) مديري المشروع بالطرق الآتية 
(20022 ,[.لة أع] 55ه01) : 
© تعزز التعاون الفعال بين أعضاء الفريق الهام استراتيجياً: كما 
يبرهن الشكل 1-13» لدى الفريق الموجود في آسيا جموعتين 
جزئيتين واضحتين. في كلا الفريقين اللذين يعملان في آسيا 
وأوروباء كما لوحظ أنه يوجد أعضاء معينون موجودون على 
الحافة ولم يتواصلوا مع معظم أعضاء الفريق الذي ينتمون إليه. 
إذا كانت الفرق المطلوب منها أن تعمل كوحدة واحدة فى 
نطاقها الخاص مهمة استراتيجياًء سوف يظهر تطبيق عملية 
تحليل الشبكات الاجتماعية هذه المشاكل في عمليات الدمج. 
© إظهار نقاط التواصل الحرجة فى التشابكات التى تظهر على 
شكل تقاظع :وظيفي أو الحدوه .داف المنعويات الخدلقة 
(الهرمية)» أو حدود جغرافية. يظهر الشكل 1-13 تفاعلات 
محدودة بين الفرق المختلفة : 
©'تُظهر المجموعتان' المزيتان الموحودتان فى .فريق اسيا تفاعلد 
دود + وقد يكون "ذلك أن كلا مدوم قعل يما 
وظيفياً ختلفاً في هذا التنظيم. وأما في التنظيمات 
الكبيرة» فمن الطبيعي أن لا يعرف أي قسم أي 
معلومات عن عمل الأقسام الأخرىء وبالتالي عدم 
معرفة الطريقة الفعالة التي يمكن أن يعملوا بها معا. 
© يوجد للتشتت المادي للفرق من خلال وجودهم في حدود 
جغرافية مختلفة نفس التأثير. ويبدو هذا أكثر وضوحاً مع 
الفريق الموجود في آسياء إذ إن تفاعل هذا الفريق مع 
الفريق الموجود في أوروبا ضعيف جداًء ولا يتفاعل على 
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الإطلاق مع الفريق الموجود في الولايات المتحدة. وقد 
تكون اختلافات اللغة والفروقات الثقافية ويُعد المسافة قد 
سببت ظهور هذا النمط السلوكي. 
© على الرغم من أن التعاون بمستويات مختلفة لم يظهر في 
الشكل 1-13» يمكن إنشاء مخطط مشابه عن طريق 
إجراء مسح على مستوى مسؤولي الإدارة العليا؛ يمكن 
أن يُظهر هذا النوع من المخططات البيانية الطريقة التي 
يكون فيها مسؤولو الإدارة العليا مضطلعين فى العلاقات 
غير الرسمية» وتكشف عملية تدفق المعلومات بالاتجاهين 
خلال هذا الفريق» وكيف أن القرارات التي يتخذونها 
تتأثر بهذه المعلومات. ويمكن تصور كيف أن القرارات 
قد تكون متحيزة لآن المعلومات التي يستقبلها أصحاب 
القرار تأي من جهة محددة من التنظيم. 
© التأكيد على وجود تكامل بين الفريق بعد إجراء خطوات باتجاه 
إعادة الهيكلية: يلجأ عادة كبار المسؤولين التنفيذيين إلى 
إجراءات إعادة هيكلة للتنظيم لجعله أكثر كفاءة وفاعلية. وقد 
أظهرت الأبحاث أنه ليس بالضرورة أن يتحسن الأداء نتيجة 
هذا الإجراء. بينما يعزى ذلك عادة إلى اختلال فى البنية 
التطلينية الرسعية ار احفات ف عياف القاد ا لك 
العاكقانت عور لوعن دنسي قدب لقو فنا انن ‏ لمقةة 
يؤدي الاتجاه نحو البنى التنظيمية السطحية إلى وجود الفرق 
المتقاطعة وظيفياً وإنشاء تنظيمات أقرب من بعضهاء ويؤدي 
إلى زخم أكبر في العمل ضمن العلاقات غير الرسمية أكثر 
منه ضمن البنية التنظيمية الرسمية المعلن عنها وعمليات العمل 
التفصيلية. 
بغض النظر عن سبب كون مستوى التعاون أقل مما يجب» 
فسوف تُظهر عملية تحليل الشبكات الاجتماعية الأنماط الخاصة 
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بالتواصل» وذلك يمنح العمليات الإدارية الفرصة لبدأ تحليل المشكلة 
وطرح حل مناسب. . وتصبح هذه الأداة فعالة جداً كلما أصبحت 
التنظيمات أكبر ومورّعة على نطاق وا سع (تخيل وجود ثلاثة أو أربعة 
نويات ند اسيل الهرمي في اليكل التنظيمي» بعدد يزيد على 
ثلاثمئة شخص يتوزعون في مواقع مختلفة حول العالم). هذا تماما ما 
يحدث في مشاريع التطوير البرمجي الموزرّعة. وفي هذه الظروف» من 
الصعب تقويم مستوى أداء العمل والقرارات التي تم اتخاذها دون 
الرجوع إلى أداة مشابهة لأداة تحليل الشبكات الاجتماعية. 


فكرة مفيدة: قم بتسهيل عمليات المشاركة في المعرفة 
والتعاون بين الأعضاء عند تحولات معينة في المراحل. 

ليس بالضرورة أن يكون جميع أعضاء ع تنظيم :ما امتضلين 
ببعضهم بعضاً بعلاقات شخصية غير و[لة أع] 5وم 0 ) 
(2002؛ وذلك ليس بسبب التكلفة الباهظة وحسبء بل 
هذا سيؤدي يقبا إلى ضغط كبير فى تدفق المعلومات 
نيص الأعضا شتات اناي وفنا مساودا لامها هق 
تكريه اناك تجديةة والسدافالة عوليياء لذناف يعيب أن 
يركز المديرون على نقاط تحؤل معينة عندما يكون هناك 
حاجة إلى المشاركة في المعرفة والتعاون. وفي حالة 
وجود المشاكل تم تشخيصها من خلال أداة تحليل 
الشبكات الاجتماعية» قد تكون بعض التقنيات مفيدة» 
مثل تقنية إنشاء مشاريع مشتركة من قبل موظفين يعملون 
في فرق مختلفة» وتقنية إنشاء منتديات جديدة من أجل 
عمليات التواصل كالاجتماعات الأسبوعية أو استخدام 
لوحات الرسائل الإلكترونية» ومنح مديري الفرق 


المشاركة حوافز مادية. 
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فكرة مفيدة: 

انتبه إلى التغيرات المفاجئة في زخم التواصل. 

قد تكون التغيرات المفاجئة في زخم التواصل مؤشراً 
تحذيرياً مبكراً للنقاط الساخنة في المشروعء إذ قد تكون 
مؤشراً على أن المشاكل قد بدأت» وقد يدل هذا على 
نقص في عمليات التواصل» أو وجود اتصالات سيئة بين 
القرق الميشاركة:وفي كلا السالعيق» لم.ينم إيضال 
المعلومات المطلوبة كاملة أو لم يتم فهم هذه المعلومات 


5-3ا لملخص والاستنتاجات 


نناقش في هذا الفصل أدوات التحكم بالتواصل والعوائق التي 
تواجهها والأنشطة المهمة والحرجة لتحسين أداء تطوير المنتج. إن 
تنسيق عملية التواصل هي عملية مهمة أيضاً لأنه يكون لدى الفرق 
مستوى أفضل من الأدام كينا نوقشت المبادئ المستمدة من نظرية 
التنظيم» مثل العلاقات الترابطية التنظيمية وآلياتهاء وأساليب التواصل 
والعقول التجميعية التى تساعد فى تعزيز التعاون الفعال بين الفرق 
المتعاونة. قد يؤدي التواصل 0 المنضبط إلى تدفق فائتض 
للمعلومات ووجود معلومات غير صحيحة. وقد تم تقديم تحليل 
للشبكات الاجتماعية كوسيلة لتتبع التغير في زخم التواصل للوصول 
إلى إدارة فعالة للاتصالات للفرق المتعاونة. 


6-3 أسيئلة للمناقشة 


1. أذكر بعض الأدوات المهمة الخاصة بالتحكم بالتواصل في 
مشاريع تطوير البريحبات المؤرّعة المراكز. 


313 


2 أذكر وناقش بعض العوائق التي تواجه التواصل. 


3. كيف يمكن الوصول إلى تنسيق أفضل للتواصل بين الفرق 
المتعاونة؟ 


4. أذكر بعض التقنيات التي تساعد على مراقبة والتحكم الفعال 
بالتواصل. 


المراجع 
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القسم الخائس 5 


دراسات الحالة 


(لفصل الرابع عشر 


مشروع الأستديو العالمي 2005 


حتى هذا اليوم» نفذت شركة سيمئز عدة مشاريع تطوير 
برمجيات باستخدام فرق موزّعة» وهي بالتالي مدركة أن الأسلوب 
الموزع لتطوير البرمجيات يؤثر بشكل كبير على جميع مراحل العمل 
المتعلق بالبرمجة. ويشمل هذا التأثير الممارسات الإدارية طاءاوط:»11) 
(2005 ,21.1 غ6]. وهناك تحديات كبيرة تتعلق بالتطوير البرمجى 
بالأسلوب الموزع عالمياً. ويركز مركز البحوث في شركة سيمنز 
جهوده لتكوين فهم أفضل لهذه التحديات وتطوير ممارسات تساعد 
في الإدارة الناجحة لمشاريع تطوير البرمجيات الموزّعة المراكز. فقد 
باشر المركز في مشروع بحثي تطبيقي يدعى مشروع الأستديو العالمي 
يسعى لتحقيق الأهداف الآتية: 

1. تطوير برمجية (30151116) بشكل ناجح بالتعاون مع فرق من 
طلاب ست جامعات من جميع أنحاء العام. ولتحقيق ذلك» 
يتم توثيق العمليات وأفضل الممارسات المستخدمةء وكذلك 
القضايا التي نتم مواجهتها. 
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2 جمع وتحليل البيانات من هذا المشروع من أجل فهم وتدوين 
مدى فعالية عملية تطوير البرمجيات المورّعة المراكز. تم 
تحديد تفاصيل البيانات التجريبية التي سيجمعها فريق من 
الباحثين يعملون في مركز البحوث في شركة سيمنزء 
الجامعات المشاركة فى تطوير برمجية (315116) هى: جامعة 
ولاية بنسلفانيا ومعهد هندسة البرمجيات في جامعة كارنيغي 
ميلون وجامعة هارفارد للأعمال. 

كانت فرق الطلاب المشاركين من الجامعات: جامعة كارنيغى 

ميلون». والمعهد الدولي لتكنولوجيا المعلومات في بانغالور 
(11118)» وجامعة مونماوث (817)» وجامعة ميونخ التقنية 
(11030)» والجامعة البابوية الكاثوليكية في ريو جراند دو سول 
(511015)» وجامعة ليمريك (آ[1). 


1-4 مشروع (8151106) 

يهدف مشروع (34511066) إلى إنشاء مركز إداري موحد لبناء 
الأنظمة الأوتوماتيكية ‏ كأنظمة التدفئة وأنظمة التكييف (11140) 
والتحكم بالوصولية والإضاءة ‏ والتي تمكن المسؤول عن المنشأة من 
تشغيل مثل هذه الأنظمة. وكمقياس عملي» تم استبدال أنظمة الأبنية 
التلقائية بمكوّنات داخلية - محاكي نظام حقل العمل (555)- والذي 
يقوم بمحاكاة المجالات التلقائية للمبنى. يظهر الشكل 1-14 وصفا 
لمخطط نظام (8/5116). 
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7 
/ 


6س . سه 87 مدن 7 من الوصول الى ملف 7« 


الشكل 1-14: سياق المخطط لنظام 16ن.آ1/15 


في ما يأتي ملخص للمتطلبات الوظيفية المهمة لنظام 
(غ1315111) : 

1. التعامل مع المكوّنات في الميدان (المكوّنات المتعلقة بمجال 
العمل التلقائى فى البناية» على سبيل المثال» مجسات أنظمة 
التدفئة وأنظمة التكييف) التي تم تمثيلها في محاكي نظام حقل 
العمل. 

2 إصدار الأوامر لعناصر الحقل من خلال محاكي نظام حقل 
العمل لإجراء تغيير قيم تتعلق بخصائص هذه العناصر عن 
طريق استقبال أمر «تغير القيمة) (/001 عنالة01-هع صقطه) 
من محاكي نظام حقل العمل ليقوم بتحديث غير متزامن لحالة 
هذه المكوّنات كما تم تمثيله في واجهة التطبيق. 
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3. تحديد الشروط المنطقية اعتماداً على قيم خصائص عناصر 
الحقل؛ وحين يتم تحقق هذه الشروط» يتم حدوث تفاععلات 
وبالتالي إصدار أوامر لعناصر الحقل. 

4. تحديد الشروط التحذيرية بشكل مشابه للشروط المنطقية؛ 
وحين يتم تحقق هذه الشروطهء يتم انطلاق تحذير لينبه 
المستخدم المناسب. وتستمر فعالية هذه التحذيرات لفترة زمنية 
محددة إلى أن يتعامل معها المستخدم ذو الصلاحيات المناسبة. 


تم إنشاء بنية مشروع (315116) بحيث يحاكي نموذج (المحور 
والنطق)» ويدعى عادة نموذج «العمل الموسع" في شركة سيمنز. 
و«المركز' هو الفريق المركزي في مركز البحوث في شركة سيمنز 
الموجود في برينستون» والذي يقوم بتنظيم عمل بعض أعضائه من 
الطلاب المتدربين. و«الفروع» هي الفرق التي تعمل عن بُعدء 
وتتكون الفرق من مجموعة من طلاب جامعات مختلفة موزرّعة في 
مناطق مختلفة في جميع أنحاء العالم. ويكون الفريق المركزي 
مسؤولا عن المتطلبات وهيكلية البرمجيات وبعض الجوانب المتعلقة 
بالتصميم واختبار النظام والدمج وإدارة المشروع وتحديد العمليات 
بشكل كلي. وأما الفريق الذي يعمل عن بُعد فيكون مسؤولا عن 
التصميم والبرمجة والاختبارات التلقاتية للوحدات للوصول إلى مهام 
معرّفة بشكل جيد وفقاً للوحدات البرمجية أو الأنظمة الفرعية التى 
يحددها الفريق المركزي خلال مراحل تحديد الهيكلية وعمليات 
التخطيط للمشروع. ويتم إدارة العلاقات بين الفريق المركزي والفرق 
التي تعمل عن بُعد عن طريق وظيفة مدير التزويد. ويوجد كذلك 
مدير تزويد لكل فريق يعمل عن بُعدء ويكون من يشغل هذا 
المنصب عضواً في الفريق المركزي. 


هناك ثمة معلومات إضافية عن مشروع الأستديو العالمي تشمل 
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لقطات من نظام ال 18/114 الذي استخدمته فرق الطلاب» تم إضافتها 
في القرص الضوثئي المرفق. 


2-4 التحديات التي تم مواجهتها فى السنة الأولى من تطوير 
نظام (3151.166) 


امتدت السنة الأولى لهذا المشروع من تموز/ يوليو 2004 إلى 
أيار/ مايو 2005. وقد تم تنظيم نظام (3451.116) على شكل إصدارات 
هندسية زمنية متتابعة تتألف من مجموعة من الوظائف التي من 
المفترض أن تكون مستقلة عن بعضها بعضاً. وكانت خطة التطوير 
تزايدية» وذلك عن طريق إضافة وظائف جديدة في كل إصدار زمني 
هندسي. وتم إبقاء الإصدارات الهندسية تحت نظام التحكم 
بالإعدادات» وأتيحت لمجموعة الاختبارات الداخلية في الفريق 
المركزي لمركز البحوث في شركة سيمنز لإجراء اختبار النظام عليها. 
وتشتمل المهام التي يسلمها في كل إصدار زمني كل فريق يعمل عن 
بُعد على بيانات العمل ومواصفات تفصيلية للمتطلبات والمهام 
الهيكلية والتصميمية واختبارات الوحدات (الخططء الحالات» 
والتقارير) وصيغة برمجية موضح عليها تعليقات مناسبة. ويجب أن 
يتم تحديد جميع هذه المهام مسبقاً حين تسليم مكوّنات ما تم 
تخصيصه للفريق الذي يعمل عن بُعد. 

فيما يُظهر تطوير البرمجيات الموزّعة المراكز مستقبلاً واعداًء 
لكنه أيضاً يواجه تحديات؛ وإذا لم يتم التعامل مع بعض هذه 
التحديات فى الوقت المناسب فقد لا يمكن التغلب عليها. وقد كانت 
الأمور التي واجهت مشروع (84151116) نموذجية لما صنفه هيرسليب 
ومويترا (2001 ,210158 4صة اءاوط816) بالأبعاد المتعددة لتطوير 


البرمجيات المورّعة المراكز: 
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© أمور استراتيجية : لا يوجد حل مثلي لعملية تقسيم البرنامج 
إلى مهام عمل تأخذ بعين الاعتبار توفر المصادر ومستوى 
الخبرات التقنية واقتران الوحدات البرمجية. وكان الهدف من 
المخطط المخصص للعمل في مشروع (©1نآ805) بسيطاً 
جداًء وفي نواح أخرى لم يضع بعين الاعتبار المهارات التقنية 
لدى الفرق التي تعمل عن بُعد والعلاقات الترابطية بين 
عناصر الهيكلية. 

© أمور ثقافية: تؤثّر الثقافة في أمور مهمة وحرجة كالحاجة إلى بنية 
قعة واستلوت بإنشاء المركل: النظني : والسامل مما الرفت 
وطرق التواصل (1997 ,11015]606). وقد أصبحت هذه 
الفروقات عقبة تواجه التواصل الفعال» كما كان واضحاً فى 
مشروع الأستديو العالمي الذي احتوى على ست فرق تعمل 
عن بُعد تتوزع في حمس دول في أربع قارات. 

© قضايا التواصل: تحتاج عملية تطوير البرمجيات» وبشكل خاص 
فى المراحل الأولية» إلى الكثير من عمليات التواصل 129ء5) 
(1994 ,81.1 66]. ويؤدي غياب المحادثات إلى وجود مفاجآت 
من المواقع المتباعدة» وهذا يؤدي إلى وجود اختلال في العمل 
والحاجة إلى إعادة صياغته. فبدلا من الدردشات السريعة 
وجهاً لوجهء لجأت فرق مشروع (805106) إلى إضافة آلية 
مخصصة للتواصل؛ فكان هناك تكرارات للمواضيع التي يتم 
فيها التواصل مع الفريق المركزي ما أَدّى إلى وجود ضغط 
عليه؛ وقد تم استخدام وسائل وأساليب مختلفة للتواصل بين 
الفريق نفسه وفي أوقات مختلفة» وبالتالي فقد التنسيق لعملية 
الغرااسو رق 2 #حدانهلا فين قمر امسق زالتشكيه 
وأصبح من الصعب جعل أنشطة الفرق المختلفة متزامنة بسبب 
عدم القدرة على الحصول على جهد موجه باتجاه واحد 
ومعلومات دقيقة عن الوضع الحالي للعمل. 
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© إدارة المعرفة: عدم وجود آلية فعّالة للمشاركة بالمعلومات وسوء 
الحفاظ على عمليات التوثيق وعدم وجود تعاون للمهام. 
ويؤدّي كل هذا إلى تفاقم مشكلة إدارة المعرفة بطريقة تُؤثر 
سلباً في الإمكانيات الفعلية لمشاريع تطوير البرمجيات المورّعة 
المراكز. وكانت الصعوبات التي واجهت الفرق التي تعمل عن 
بُعد في فهم المتطلبات والنية التصميمية دليلا على ذلك» فهم 
لم يشاركوا في إعداد المتطلبات والهيكلية. فقد كانت 
المواصفات الموضوعة للمتطلبات والهيكلية» من وجهة 

©#أمور تتعلق باإدارة المشروع والعمليات: عدم وجود 
تزامن» وبشكل خاص عدم وجود معالم ومعايير واضحة 
لنقاط البداية والنهاية في المهام الموكلة» ما يفاقم المشاكل 
في مشاريع تطوير البرمجيات الموزّعة المراكز. وتتمتع الفرق 
التي تعمل عن بُعد بالحرية الكاملة في تحديد العمليات 
ومعايير معالم العمل» ما يؤدي إلى ظهور صعوبات في مسار 
العمل. 

© أمور تقنية: وجود تناقضات في قدرات وإعدادات الشبكات 
وصيغ غير متوافقة للبيانات وإصدارات مختلفة للآدوات نفسها 
هي بعض ما يواجه الأمور التقنية عادة. وقد ترك في مشروع 
ال (31516) لكل فريق يعمل عن بعد الحرية فى إعداد بنية 
تحتية خاصة به. ولم تكن أدوات البريجة المتوفرة لهذه الفرق 
تدعم عمليات البريجة في مواقع مختلفة. 


4- 3 المنهجية للسنة الثانية من تطوير نظام (3151.16) 


يواجه التعامل مع الأمور المتعلقة بالتطور الموزع مجموعة من 
التحديات» وتم ملاحظة معظم هذه التحديات فق مشروع (ع11ن32151) 


خلال السنة الأولى. وبشكل أساسي» عندما تم تشغيل طلاب مازالوا 
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على مقاعد الدراسة». احتاج الفريق المركزي إلى بعض الوقت من 
أجل تجربة هذه الأمور وتطوير البنية التحتية الضرورية وإنشاء مهام 
البرمجة الموكلة إلى الفرق التي تعمل عن بُعد. وتقوم الأقسام الآتية 
من هذا الفصل بتفصيل الاستراتيجية المتبّعة في السنة الثانية. 


1-3-4 سير العمل 
قام الفريق المركزي بتحديد الوظائف والمهام لكل من الفريق 
المركزي والفريق الذي يعمل عن بُعد. ويتكون الفريق المركزي من 
الوظائف الآتية (مع بعض خصائص مسؤوليات هذه الوظائف) : 
© مهندس المتطلبات: يحتفظ بالمتطلبات الوظيفية المهمة ومحددات 
ويتأكد من صحة مواصفات التصميم التي أنجزها الفريق 
الذي يعمل عن بعد. ويحافظ على القدرة على التتبع في هذه 
المهام. 
(يتضمن ذلك التأكد من الفهم الصحيح لهيكلية النظام 
الهرمى للتقئية المنتخدمة فى عمليات التطبيق. 
© مهندس عمليات الدمج والتكامل (مسؤول عمليات البناء 
البرمجي) : يحافظ على مستودع تخزين الشيفرة البرمجية وبيئة 
إنشاء الوحدات المبرمجة تلقائياً؛ ينفذ الاختبارات المتعلقة 
بالدمج ويعمل على صيانتهاء كما يتأكد من أن الفريق الذي 
يعمل عن بُعد قد نقذ عمليات الدمج. 
© مدير البنية التحتية: يحافظ على البنية التحتية ويدير جميع الأمور 
المتعلقة بالبنية التحتية التي تطرأ في جميع الفرق. 
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ويحافظ على اللباقة في استخدام نظام 11ة/. ويشمل ذلك 
اختبار وتدقيق جميع نواحي نظام 17111 (يوجد المزيد عن 
وظيفة نظام 11ة/لا في القسم الآني). 
بُعد في ما يتعلق بالمهام الموكلة إليهم؛ التأكد من أن جميع 
عمليات التواصل تتم باتباع أسلوب مناسب» ويقوم بتدريب 
إداريي المشروع وتقنيي التحكم والسيطرة في الفرق التي 
تعمل -عق بعد: وعُثّل هذه الوظيفة خلقة الوضل الأساسية بين 
الفريق المركزي والفريق الذي يعمل عن بُعد. 

© مدير ضمان الجودة: ينشئ اختبارات القبول لكل مرحلة عمل 
ويتأكد من أن مراحل العمل تخضع للمعايير الموضوعة؛ 
أصدرتها الفرق؛ يتأكد من أن العناصر الثابتة فى الهيكلية قد 
التقارير حول العيوب وعملية تتبعها. 
والمسؤوليات كلما تطلب الأمر؛ بحدد العمليات الحديدة 
ويحافظ على العمليات الحالية في قسم العمليات في نظام 
أكة/ةا؛ ويتأكد من أن الفريق المركزي والفرق التي تعمل عن 

في ما يأتي وظائف الفرق التي تعمل عن بُعد وبعض صفات 
المؤولياض ليده الوظانت: 

© المبرمج: يكما جميع المهام (11: لتطلبات والت لتصميم و عمليات 
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متطلبات الجودة؛ التأكد من أنه قد تم الالتزام بالتصميم المقرر 
أثناء عملية البريجة؛ كتابة وتنفيذ الاختبار التلقائي للوحدات 
البريمجية؛ الالتزام بتنفيذ عمليات الدمج والتكامل. إن جميع 

© قائد الفريق: يتعامل مع جميع الأمور التي تتعلق بالعلاقة مع 
مدير التزويد؛ يتأكد من أن الفريق يكمل جميع المهام كما هو 
مخطط لها في خطة المشروع» والالتزام بالوقت» والتأكد من 
تحقق متطلبات الحودة. 
من أن جميع مواصفات المتطلبات الموكلة إلى الفريق قد تم 
تسليمها فى المواعيد المحددة. 

© مدير المصممين: يُسهّل فهم الفريق لمواصفات الهيكلية 
والتصميم؛ والتأكد من أنه تم تسليم جميع مواصفات العمل 
الموكل إلى الفريق قد تم تسليمها في المواعيد المحددة. 

© مدير ضمان الجحودة: مسؤول عن ضمان جودة كل مايتم 
تسليمه من البرمجيات وجميع المهام الأخرى أيضاً؛ كما إنه 
مسؤول عن تحقيق معايير الجودة التي تم تحديدها. 
والمحافظة عليها. 

© مدير إدارة العمل والتوثيق : يطبق محددات جميع وظائف الفريق 
الذي يعمل عن بُعد؛ ويتأكد من استخدام نظام 11لا 
بالطريقة المناسبة - سوف يكون مسؤولا عن جميع المهام الخاصة 
بنظام 18/111 التي يسلمها الفريق. 

يقوم الفريق الذي يعمل عن بعد بتحديد شاغلى هذه الوظائف 

في بداية عملهم. كما يستطيعون تغييرهم في أي وقت خلال 
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المشروع (لأنهم ما زالوا في المجال الأكاديمي كطلاب» ويتطلب 
ذلك التعرض إلى وظائف مختلفة)» ولكن لا بد من إبلاغ الفريق 
المركزي بهذه التغييرات التي تُجرى في بنية الفريق. 


حدد الفريق المركزي أيضاً العمليات التي تعالج جميع الأمور 


© عملية إدارة التهيئة: تصف طريقة استخدام مستودع الوثائق 
والشيفرة البرمجية المصدرية في موقع الفريق المركزي. 

© عملية التواصل: تصف أهداف واستخدامات أنواع التواصل 
المختلفة المتوفرة» كنظام 78/14 والقوائم البريدية واتصالاات 
المؤتمرات. 

© عملية التصميم والبرمجة: تصف الخطوات المتبعة لعمليات 
التصميم والبرمجة منذ بدايتها عندما يصدر الفريق المركزي 
النسخة الأولية لخطة البرمجة إلى نهايتها عندما يقوم الفريق 
الذي يعمل عن بُعد بتسليم المهام المتوقعة منه» والتي وافق 
عليها مدير التزويد. ويشمل ذلك المفاوضات التي تتم حول 
خطة البريجة الموضوعة لمكوّنات نهاية كل مرحلة عملء والمهام 
التي يجب أن ينجزها كل فريق يعمل عن بُعد خلال فترة 
زمنية معينة» والمعايير التي يضعها مدير التزويد لقبول ما يتم 
تسليمه من الفريق الذي يعمل عن بُعد. 

© عملية الدمج: تشمل هيكلية المستودع وبيئة عملية الدمج 
التلقائي والطريقة التي تعمل بها وإمكانية استخدامها من قبل 
الفرق التي تعمل عن بُعد. وتقوم بتصنيف التعديلات إلى 
تعديلات مستقلة وتعديلات مترابطة» والكيفية التي يجب أن 
يتعامل بها المبرمجون في الفريق الذي يعمل عن بُعد ومسؤول 
عمليات الدمج في الفريق المركزي مع هذه التعديلات. 
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© عملية إدارة التغيير : تحدد العملية التي يتم من خلالها طلبات 
إجراء تعديل وإظهار تأثيراتبا وضمان مستوى معينٌ من القدرة 
على تتبعهاء ويشمل ذلك خطوات عمل التعامل مع 
التعديلات باستخدام أداة أوتوماتيكية تشتمل على آلية لأخذ 
آراء أصحاب القرار حول الموافقة على إجراء التغييرات» 
بافتراض أن «التغييرات هي تغييرات إيجابية». وتؤيد 0 
على المتطلبات» والهيكلية» ومواصفات التصميم التي يزود بها 
الفريق المركزي». أي تراك الا تردتي لماي اللعهيم ادي 
تقوم بها الفرق. 

© عملية الوبلاغ عن العيوب وتتبعها: تصنيف العيوب إلى عيوب 
تشغيلية وعيوب برمجية وعيوب فى الوثائق» كما تتضمن 
وصف آلية إرسال العيوب» وتوكيل العيوب إلى المبريجين» 
وإصلاح العيوب» والتحقق من صحتها باستخدام أداة تقوم 
بذلك تلقائيا. 

عملية الاجتماعات: تضع الخطوط العريضة لتنظيم الاجتماعات 
المتلفزة الأسبوعية بين الفرق التي تعمل عن بُعد ومدير 
التزويد الذي يعمل في الفريق المركزي. وتتضمن عملية 
التنظيم هذه إعداد جداول عمل الاجتماعات التي يقوم 
الفريق الذي يعمل عن بعد بكتابتها. وتصف هذه العملية 
أيضاً ما يجب عمله قبل الاجتماع وخلاله وبعده أيضاً لتأكيد 
فعالية هذه الاجتماعات. 

© عملية إذارة المخاطر: تحدد القواعد المستخدمة في تتبع المخاطر 
التي تؤثر عل اتروع والتعائل تبعها وترقم من جميع أعضاء 
الفريق المركزي وأعضاء الفريق الذي يعمل عن بُعد إضافة 
المخاطر التي يتوقعونما إلى النماذج. ويتوقع من الفريق المركزي 
استخدام هذه النماذج كدليل لاتخاذ الإجراءات المناسبة لتعديل 
ذلك. 


330 


© عملية د تقويم أداء الفريق : يبين كيفية تقويم أداء الفريق أسبوعياً؛ 
وعلى 0 تقويم الأداء هذا سيبقى داخلياً في الفريق 
المركزي» ف فسيتم إعلام ومكافأة الفريقين ذوّي التقويم الأعلى. 


2-3-4 التعاون والتواصل وإدارة المعرفة 

كانت الجهود المبذولة فى إرساء التعاون والتواصل هى الجانب 
الأضفتت فى إتجازات العام الأول: ول يكن هناك به نحي متو ره 
بشكل خاص للمعلومات والمعرفة. ويستخدم الفريق المركزي الآن 
نظام 17/111 في المشروع» وهو عبارة عن تطبيق من تطبيقات شبكة 
الإنترنت يتيح للمستخدمين إضافة محتويات كما في منتديات 
الإنترنت» ويتيح كذلك لأي كان إجراء تعديلات على هذه 
المحتويات. وقد قرر الفريق المركزي استخدام تطبيق (7/11ا 316018) 
(الشكل 2-14) (نكلة/1اهنلع]/2/ لماع :2.0 نلعدس كل ماعحص// :ماخط) . 


في ما يأتي بعض الطرق التي يمكن استخدام نظام 18314 فيها 
لتحقيق التعاون والتواصل وإدارة المعرفة : 


© المستودع المركزي للوثائق: نظام 78/314 هو المستودع الوحيد 
لحب الرياتى ال نط بالتزرم «لالغفل الركل بنج الفرى 
التي تعمل عن بُعد. تتم إضافة القسم المتعلق بالفريق 
المركزي (تحت مسمى 'المواضيع الرئيسة») والحفاظ عليه 
بصرامة بواسطة مسؤول نظام 111. ونعرض في هذا 
السسيم النظام الذي يتم تطويره بشكل كامل ودقيق ومحدث 
ول 

© مستودع الوثائق الخاصة بمواقع العمل البعيدة: نظام 1/111 هو 
أيضاً المستودع الوحيد لجميع وثائق الفرق التي تعمل عن بُعد. 
ويتم تشجيع الفرق التي تعمل عن بُعد على إنجاز مهامهم 
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المتوقعة منهم والتعاون من خلال المساحة المتوفرة لهم في 
«قسم صفحات الفريق». وتستطيع الفرق التي تعمل عن بُعد 
كذلك استخدام هذه الصفحات كمكان لمحصص لإنشاء 
الوثائق المطلوبة من قبل الفريق المركزي قبل أن يتم نقلها إلى 
مكانها الصحيح في صفحات الفريق المركزي. ويضمن هذا 
أيضاً وضوحاً كاملاً لإنجازات جميع الأعضاء في أي مرحلة 
من المراحل. 

© المناقشات: تحتوي كل صفحة من صفحات نظام 1714 على 
صفحات محادثة مرتبطة بها. ويستخدم الفريق المركزي هذه 
الصفحات لجمع الأسئلة والحصول عل الآراء 
والانطباعات». وأي أمور أخرى يتطلبها من الفريق الذي 
يعمل عن بُعد. وقد يتم إرسال هذه الأمور مباشرة عن 
طريق مدير التزويد أو في الاجتماعات الأسبوعية مع 
الفريق الذي يعمل عن بُعد. ويقوم الفريق الذي يعمل عن 
بُعد بتوثيق الإجابات أو التوضيحات عن تساؤلاتهم. ويمنح 
هذا الفريق الذي يعمل عن بُعد إمكانية طرح تساؤلاته 
بشكل فوري وربطها مع مهام خاصة في نظام 17814. كما 
يقومون أيضا بإجراء نقاشات مع فرق أخرى تعمل عن 
بُعد لتوضيح القضايا أو التوجيهء وبذلك يتم الحد من 
قنوات التواصل التى تنشأ عن الإجابة عن نفس التساؤلات 
لكل فريق يعمل عن بُعد. 

© ما ينبغي عمله (12026 86 160): عندما تكون إحدى المهام أو 
قسم منها غير مكتمل» يمكن الإشارة إلى ذلك بسهولة عن 
طريق علامة (ما ينبغى عمله (181) معرفة مسبقا. وتظهر هذه 
لهام بشكل تلقائي :في قسم لآما ينغي عله 11898 ويمكن 
الدخول إليه من الصفحة الرئيسة في نظام 78/114. 
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ومعجمزك ل صدت بهد راملا ل 
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الشكل 2-14: الصفحة الرئيسة فى نظام 11لا عا1نآ[ك/ة) 


© إعلانات نظام 181: حين يتم إنجاز تعديلات مهمة أو 
جذرية» يعلن الفريق المركزي عن هذه التعديلات في قسم 
«جديد وجدير بالملاحظة» (لاع0 2016770115 42) فى الصفحة 
الرئيسة في نظام 1831. ويتم إعلان هذه التعديلات لجميع 
الفرق ذات العلاقة عن طريق البريد الإلكتروني. وتُستخدم 
هذه الخاصية في حال إجراء تعديلات على نظام 1/114ا» 
وليس التعديلات التى تؤثر فى المتطلبات أو الهيكلية أو 
بواساك لصوم » الويف الساف معواه ‏ طريق عي 
إدارة التعديللات. 
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© سجل الأحداث: يسهل سجل الأحداث عملية طرح المشاكل 
والأمور الأخرى المتعلقة بعملية البرمحة بشكل صادق ومنفتح. 
ويتيح نموذج بسيط وسهل الاستخدام المجال أمام جميع 
المشاركين بالمشروع لسرد المشاكل التي يواجهونها أو المجالات 
التي يشعرون أنها بحاجة إلى التطوير. 

© تحليل عملية التشغيل بعد إتمامها: في نهاية كل مرحلة» يعقد 
مديرو التزويد تحليلا لعملية التشغيل بعد إتمامها (-056م 
مع 01م مع فرقهم لمناقشة الطريقة التي تم ها التخطيط 
للعمل وتنفيذه» وكيف يمكن الاستفادة من المرحلة الأولى فى 
المراحن الالاتحقة ورت عركن هلم المبافشنات ف فس عنواله 
«ما بعد الفترة البرمجية التكرارية» في الصفحة الرئيسة من نظام 
لا . 


3-3-4 المتطلبات 

إن نظام 181 هو الوسيط الأساسي لتحديد مواصفات 
المتطلبات بما فى ذلك المتطلبات الوظيفية المهمة ومحددات 
الوظيفية المهمة على شكل حمل باللثة الاتجليزية تقتريح «الوظائفك 
1 مجموعات منطقية مختلفة وفمقا لترابطها مع هذه المتطلبات. 
في تطبيق (65طاء6ع108 80:1320) ومقسمة إلى رزم منطقية (وفقاً 
لعمليات التجميع فى المتطلبات الوظيفية المهمة)» كما تتضمن 
وصفاً لحالات الاستخدام باستخدام النموذج التقليدي للعملية 
المنطقية الموحدة. 
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الشكل 4- 3: مثال على مواصفات واجهة المستخدم 


يتم ربط خطوات حالات الاستخدام المرتبطة بالوظائف الظاهرة 
عبارة عن نماذج الشاشة (يتم إنشاؤها باستخدام تطبيق (815) 01/110705016 
هزوذلا) مع وضع علامات على الخطوات التي تشير إلى ترتيب الخطوات 
التي قام بها المستخدم على واجهة التطبيق لإنجاز إحدى الوظائف. يتيح 
نظام 17/11 محافظة الفريق المركزي على الترابط بين هذه المهام المتعددة 
بطريقة بسيطة وقابلة للاستخدام بأقل جهد ممكن على الفريق المركزي. 
أولاء يتم تصنيف المتطلبات الوظيفية المهمة إلى مجموعات مختلفة ؛ 
ظيفية مع مواصفات حالة استخدام واحدة أو أكثر؛ يتم ربط خطوات 
حالات الاستخدام بدورها إلى أجزاء مواصفات واجهة التطبيق بالطريقة 
المناسبة. ويتم أيضاً الحفاظ على القدرة على تتبع المتطلبات الوظيفية 
عل 0ك وعدت تتبع (الشكل 14 -4). 
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لط جمعمعاك للالا كن ٠‏ جامعدع أبوعا! لمممتاعوب التحوموةا ل 
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الشكل 4-14: القدرة على التتبع بدءاً من المتطلبات إلى خطة المشروع 


4-3-4 الهيكلية والتصميم 
لقد تم تحديد هيكلية النظام في مرحلة مبكرة لأنها المحور 
الذي يقوم عليه نجاح المشروع. يقوم الفريق المركزي بتوفير الأمور 
التالية للهيكلية التصميمية (2002 ,[.21 66] 5اهعدمء0) في نظام 78/111 : 
© عرض المكؤّنات والارتباطات (©0480) : تبدأ مواصفات الهيكلية 
من المجالات الأكثر أهمية للنظام يليها واجهات التشغيل 
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للنظام. ويشمل هذا واجهات تشغيل المستوى الأول في النظام 
(المكوّنات والارتباطات)؛ وفى بعض المكوّنات الأكثر أهمية 
يتم إجراء مستوى ثُانٍ من التجزيء لنفس الواجهة. 

© عرض العملية: وهي تمثيل تشغيلٍ للعمليات التي لها علاقة في 
تنفيذ نظام (8151.16). تظهر المكوّنات التشغيلية الروابط بين 
واجهة المكوّنات والارتباطات من المستوى الأول مع 
العمليات» والآلية التي تتواصل بها العمليات المختلفة مع 

© عرض الوحدة: وهو عرض ثابت يُظهر وحدات تطبيق 
البرمجيات لنظام (38051.116) وتوابعه. 

© عروض تخصيص المهام: نُظهر واجهة النشر مخططاً للأجزاء 
البرجية لواجهات المكوّنات والارتباطات مع الأجزاء ماده 
بالاجهزة» وتوضح الطريقة التي يتم بها توزيع الاأنظمة 
الفرعية المختلفة للنظام (20151.116) مع مختلف المعدات. وتركز 
التي سيستخدمها مبر مجو المشروع. 

© واجهات الاستخدام: وهي عبارة عن واجهات للوحدات مرئية 

© محددات السلوك: تونق هذه المحددات الطريقة التى تنفذ بها 
الهيكلية المفترضة للمتطلبات الوظيفية. تم استخدام المخططات 
التسليلة للإطندار 1,5 من لقة التمدحة المركوة للفوتيق را 
على واجهات الوحدات. والمقصود باستدعاء الوسائل الموضحة 
فى المقطط فلك الوستاكل:الموجحوذة- فى الواجهات لوحندات 
خاصة بها. 

من المهم ملاحظة أنه يتم إنجاز تصميم المتطلبات والهيكلية 

وإعادة عمل متعلق بها بتفصيل أكبر في مكان واحد في نظام 8/114آ. 
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5-3-4 أمور تقنية 


نظراً إلى أهمية وجود بنية تحتية متكاملة جيداً في المواقع 
المختلفة الموزعة عبر الحدود الجغرافية» يقوم الفريق المركزي ببذل 
جهد لا بأس به في إنشاء بنية تحتية توفر الحلول بشكل عملي. يتضمن 
نظام علث/لا 00 جميع الأدوات والتقنيات التي ابيا الفترة 
الكلية للمشروع. كما يقوم بتفصيل الإعدادات اللازمة لكل من المواقع 
التي تعمل في المشروع ويقوم بتفصيل استخدامات هذه الأدوات أيضا. 

إختار الفريق المركزي الحلول التي توظف أسلوب الاستعانة 
بالمصادر المفتوحة لمعظم الأدوافة الع عم لأنها توفر فوائد 
متعددة. وقد ظهرت هذه الحلول في مشاريع تطوير البرمجيات 
المورّعة المراكز بشكل أفضل من أدوات التجارة المتوفرة؛ هذه 
الأدوات متوفرة مجاناًء وهذه فائدة للفريق الذي يعمل عن بُعد لأنهم 
يعملون كمتدربين وهي متوفرة بسهولة ولا تتطلب من الفريق 
المركزي أن يقوم بتخزينها أو اتباع أي إجراءات خاصة؛ كما تتوفر 
فيها مجموعة كبيرة من الوثائق التي توضح طريقة إعدادها 
واستخدامها بشكل وافٍ. 

حصل الفريق المركزي على مجموعة أدوات (1820:ه6) الخاصة 
بهندسة البرمجيات الحاسوبية» والتي تشتمل على أدوات تصميم 
وبرمجة (1086]062 6011320) المتوافقة بشكل كبير من تطبيق 
(5601010 1هداكل؟ '151181) وتطبيق (10ه12]10م '218:1). سمحت (1320:هط) 
للطلاب باستخدام مجموعة أدواتها مجاناً.» بالإضافة إلى تدريب 
الفريق المركزي تقنياًء وتم تسجيل هذا التدريب بشكل مرئي وتوفيره 
عن طريق نظام 18/114 لجميع المواقع التي تعمل عن بُعد. 

كوّن الفريق المركزي مجموعة من المشرفين المدربين على 
استخدام نظام 1111 للأجزاء المتعلقة بالبنية التحتية. كما تم عقد 
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تدريبات مختصة بهذه الأجزاء؛ شمل هذا تدريبات تتعلق بتركيب 
الأدوات والتعامل مع أدوات إدارة الإعدادات واستخدام نظام 114/لآ 
أيضاً. يقوم جميع المبرمجين في الفريق الذي يعمل عن بُعد بإنشاء 
صفحات خاصة بهم وأخرى خاصة بالمجموعة في نظام غعلذ/لاء 
بحيث تعرض لهم خصائص نظام 711 التي سوف يستدعونها عند 
الاستخدام خلال المشروع. قام الفريق المركزي بعمل محاضرات 
باستخدام العروض التقديمية فيها لعرض الأمور المهمة» كالتركيب 
واستخدام أجزاء البنية التحتية وإدارة المشروع والعمليات والأمور 
التي تم تعلمها من العمل في السنوات السابقة وقراءة مواصفات 
المتطلبات والهيكلية لنظام 781. وقد تم تصوير هذه المحاضرات 
أيضاً ووضعها في متناول اليد في نظام 78314. فعندما تبدأ الفرق التي 
تعمل عن بُعد العمل يتم تدريبها على عرض ومناقشة هذه 
التسجيلات كفريق واحد. 


6-3-4 أمور استراتيجية: التخطيط والتحكم 

والمراقبة أموراً سهلة في أي وقت من الأوقات. بل وتصبح أيضاً أكثر 
تعقيداً عندما يكون هناك مجموعات موزرّعة على مناطق جغرافية 
مختلفة. ومن الأمور التى تجعل هذه الآمور صعبة اختلاف التوقيت 
الأخرى خلال وقت العمل. إضافة إلى ذلك» فإن ما يعقّد الأمور 
أكثر هو النقص في معرفة المهارات الفردية لكل عضو من أعضاء 
الفرق التي تعمل عن بُعد. 

1-6-3-4 توزيع العمل 

لدى الفريق المركزي خطوط عريضة يتم على أساسها التأكد من 
أنه قد تمت مواءمة عمليات توزيع العمل مع التعقيدات المتعلقة 


339 


بتطوير البرمجيات الموزّعة المراكز. وهذه الخطوط العريضة هي : 
© أن تصبح الفرق خبيرة في مجال وظيفي محدد: تم تصميم وإنشاء 
بعضها بشكل كبير. وهذا يقلل الحاجة إلى تبادل التواصل بين 
الفرق التي تعمل عن بُعدء ذلك أن كلاً منها مسؤول عن 
وحدة معينة أو مجموعة وحدات لا تعتمد على الوحدات التى 
تقوم بإنجازها الفرق الأخرى. 
© إنشاء نظام (©]31511) باستخدام طريقة البرمجة التزايدية: تنشأ 
كل فترة برمجية تكرارية عن إصدار جزء تنفيذي لقسم من 
نظام (845116). وهذا يعني أنه يتم إضافة الوظائف تدريجياً 
في كل فترة برمجية تكرارية. 
© إنشاء نظام (3151.1:6) باستخدام طريقة البرمجة لفاك من 
الجزء إلى الكل: قبل برمجة كل وحدة»؛ يجب أن تكون 
الوحدات التى تمثل متطلبات لوحدات أخرى قد تمت برمجتها 
أو في طور البريجة. قام الفريق المركزي بإنشاء عرض لعلاقات 
لاحقاً) لتحقيق هذا الهدف. 
© تجنب إنشاء الفرق التي يُطلب منها تعلم تقنيات متعددة: أنشأ 
الفريق المركزي المنظور التقني للنظام وأوكل وحدات العمل 
إلى الفرق وفقا للخبرات المتوفرة لدى كل منهاء لذلك يجب 
أن يكون المطلوب من كل فريق يعمل عن بُعد التركيز (وهذا 
لقد تم استخدام التقنية الخاصة بمصفوفة هيكلية التصميم 
(1523) (2001 ,رعسنم8:0) لفهم وعرض العلاقات الترابطية بين 
الوحدات الخاصة بالنظام (الشكل 5-14). 
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قبل البغير 
معالجة الأوامر 
الإعدادات 
مخزن القيم 
دخول البيانات 
تقويم الشروط 
معالجة أوامر تغيير 
القيم 
مسؤول التوافق 
عرض الخاصية 
معالجة التنبيهات 
منظم قواعد 
التنبيهات 
معالج ومظهر 
الهيكل التنظيمي 
عرض التنبيهات 
منظم قواعد (1.4[8) 
محرر القواعد 


تسجيل الدخول 


عدد العلاقات 
الترابطية 


0: 0:1 1 1 1 22-3 1 210.11 1 2 


الترميز: 1 بالخط الغامق - تستخدم العلاقات الترابطية 
1 بالخط العادي - علاقات ترابطية عادية 


الشكل 5-14: مصفوفة التصميم الهيكلي لوحدات نظام (3/151116) 


341 


تساعد مصفوفة هيكلية التصميم في إنشاء عرض زمني لعمليات 
تطوير النظام» ويرمز هذا العرض إلى أبكر فترة زمنية يمكن فيها 
تطوير الوحدة مباشرة بعد أن تكون جميع الوحدات التي تلزم ذلك 
جاهزة» وأبعد فترة زمنية يمكن تطوير الوحدة فيها دون حدوث 
تأخير في الوحدات الأخرى التي تعتمد عليها وذلك إن وجدت. 


تم إنشاء العرض التقني أيضاًء ما يوفر معلومات حول التقنيات 
التي يحتاجها تطبيق كل وحدة. والهدف من هذا العرض هو تحديد 
العمل الخاصة به. 


يستطيع الفريق المركزي إنشاء عرض مثالي لمهام العمل من 
خلال مجموعة من العروض لعمل البرمجة (الشكل 6-14). يحتوي 
هذا العرض على : 


© الوحدات التي تم توكيل كل فريق من الفرق الست بها. 

© الفترة الزمنية التي يجب خلالها تسليم كل وحدة. 

© قدرة التشغيل المتوقعة في نباية الفترة اعتماداً على الوحدات التي 
تم تنفيذها في هذه الفترة. 

© التقنية التي يجب أن يعرفها كل فريق لتطبيق الوحدات الخاصة 
م 

© الوحدات المهمة في نظام (3051.116) التي سيكون كل فريق 
مسؤولا عن تطبيقها. 

© طول الفترة الزمنية التي يحتاجها الفريق في العمل في مشروع 
نظام (38051116). 


© الفترة الزمنية المتوفرة للفرق لتعلم التقنيات التي يحتاجونها. 
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2-6-3-4 التخطيط للمشروع والتحكم به 
يستخدم الفريق المركزي نظام 711 للتخطيط للمشروع 
والتحكم به. يتم تفصيل المراحل التي تستمر خلال فترة تنفيذ مشروع 
التطوير بتوفير المعلومات الآتية في نظام 18/111: 

© الوظيفية: القدرة التشغيلية الكلية المتوقعة في نهاية كل مرحلة. 

« الوظائف الأولية: الوظائف الأولية التي تحتاجها كل وظيفة 
أساسية من أجل إنجازها. 

© المصادر: الفرق التي تعمل على كل وظيفة أولية (هذا يأخذ بعين 
الاعتبار العروض المختلفة والمتعددة التي تم إنشاؤها للمهام 
الموكلة» والمهارات التي يمتلكها كل فرد من الفريق الذي 
يعمل عن بُعد في جميع الأدوات والتقنيات التي تم توزيعها 
كجزء من التدريبات التي يقوم به على نظام 17/111 وحالة 
ومستوى عمل كل عضو من أعضاء الفريق الذي يعمل عن 
بعد). 

© موعد التسليم : لكل وظيفة أولية. 

© وصف المسؤوليات: تشمل وصفاً كبير الأهمية للمهام والمكوّنات 
والروابط والوحدات والواجهات والوسائل التي سيتم 
تطويرهاء واختبار القبول للوظيفة الأولية» إضافة إلى أي 
معلومات أخرى متنوعة ذات علاقة حول التقنية التي تحتاجها 
الوظائف الأولية. 
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مسج وود (إ811) فد مز 
عع ممم اجيم ضويب صم صب وص 


ل 
ممم صعودصضة (رزأ 8 /81) فم رز أورو ها 
ميم ليم تويب حب ضري وير 


يعرض تقويم المشروع المعالم المهمة التي يجب إنجازها خلال 
مرحلة ما. وقد حدد الفريق المركزي أيضاً نموذجاً مخصصاً لتتبع 
عمليات المشروع والتحكم بها. يتم إنشاء هذا النموذج عن طريق 
مراحل العمل وعن طريق الوظائف الأولية أيضاً. ويُستخدم النموذج 
من كلا الفريقين» الفريق المركزي والفريق الذي يعمل عن بعد 
لتحديد حالة مهام هندسة البرمجيات اللازمة لإكمال المهام المتعلقة 
بالوظائف الأولية. ويتطلب النموذج أيضاً أن تقوم الفرق بأخذ معايير 
الجودة (سيتم وصفها لاحقاً) ذات العلاقة بعملية تطبيق جميع 
الوظائف الأولية الموكلة إليهم بعين الاعتبار. ويُظهر النموذج أيضاً 
الوضع الحالي لعملية القبول واختبارات الدمج حالما تتم عمليات 
التسليم من الفريق الذي يعمل عن بعد ليقوم الفريق المركزي 
لانتهاء المهمة المعنية» ولكن ما إِنْ يتم ربطها بالأعمال المتعلقة بها. 
حتى يتم إنشاء معظم هذه المهام باستخدام نظام 71 ويتم تنظيمها 
باستخدام وحدات ذات مستوى متقدم. وهناك نموذج يُستخدم فى 
تحديد مخططات الطبقة لكل وحدة عالية الأهمية» ومخططات 
التتابع» وتحديد حالة اختبار الوحدة» ومراجعة النص البرمجى» 
وغير ذلك. 


مع وجود برنامج زمني للاجتماعات بين كل فريق يعمل عن 
7-3-4 ضمان الجودة 


يوجد نواح متعددة لضمان الجودة تم إدراجها ف الممارسات 
والعمليات التي تجري على المشروع : 
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© معايير الجودة: هذه المعايير التى حددها الفريق المركزي لما يسلمه 
الأخطاء»؛ ومعايير عمليات المراجعة وإبداء الرأي» ومعايير 
الإجراء» والمعايير للمشروع ككل. وباستخدام ما مجموعه 14 
معياراً موزعاً على هذه الجوانب الأربعة» ويقوم مدير التزويد 
أسبوعياً بتقويم ما تسلمه الفرق» وعن طريق استخدام عملية 
تقويم الفريق التي تم ذكرها سابقاء يتم إعلام أعلى فريقين 

© معايير لغة البرمجة: قام الفريق المركزي بسرد معايير لغة البرمجة 
(#©) التى تُعتبر أساساً للخطوط العريضة للغة البرمحة 
المستخدمة في بريجة الأعمال المقترحة. ومع ذلك» فبما إن 
أحد معايير الجودة التي يتم تقويم الفريق الذي يعمل عن بُعد 
على أساسها هى عدد التجاوزات لمعايير لغة البريحة» وعلى 
هذا الأساس يُتوقع من أفراد الفريق أن يلتزموا بجميع معايير 
لغة البرمجة» أو يقوموا بتطوير هذه المعايير عن طريق عملية 
إدارة التعديل وبإشراف مدير التزويد المسؤول عنهم. 

© اختبارات القبول: يتم سرد اختبارات القبول لكل وظيفة فرعية 
عن طريق مدير ضمان الجودة في الفريق المركزي. ويتم توفير 
هذه الاختبارات لجميع الوظائف الفرعية التي تشكل مجتمعة 
مرحلة عمل قبل أن يتم إنجاز هذه المرحلة. 

© اختبارات الدمج: كما هو الأمر في اختبارات القبول» يتم أيضاً 
الجودة لكل وظيفة في مرحلة العمل وقبل المباشرة في 

© التحقق من شيفرة البرمجة واختبار صحتها وفعاليتها ومراجعة 
النص البرمجي: يتم اختبار شيفرة البرمجة ومراجعة الشيفرة 
المصدرية وصيانتها بواسطة الفريق الذي يعمل عن بُعد. وعن 
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طريق استخدام النموذج (يتم إنشاؤٌه عن طريق وحدات عالية 
الأ*مية) الذي تم تزويد الفريق الذي يعمل عن بُعد به في 
نظام 278114 يقوم الفريق الذي يعمل عن بُعد بتوثيق وضع 
هذه النواحى» وإنشاء روابط مع طبقات اختبار الوحدة 
التلقائي في المستودع البرجي. 


8-3-4 التدريب 


إن تدريب الأشخاص على العمليات والأدوات والتقنيات وعلى 
المشروع بشكل عام هو أحد المعايير المهمة للنجاح. وتتناسب مقدرة 
أي تنظيم على أداء ذلك بكفاءة وفاعلية عكسياً مع درجة التشتت 
الجغرافي لأعضاء الفريق. ويستخدم الفريق المركزي عدداً من 
التقنيات المختلفة في السنة الثانية للمشروع بعد إدراك مغزى ومدى 
صعوبة الوصول إلى هذا الهدف. ويتم تحديد التفاصيل لكل ناحية 
من النواحي بدرجات متفاوتة من التفصيل في نظام 11/111 باستخدام 
لأعضاء الفريق الذي يعمل عن بُعد على الأقل قبل أسبوع من 
الاجتماع الأول ويُطلبٍ منهم أن يبدأوا القراءة من خلال نظام 
17/1. يكون الاجتماع الأولى عادة مع الفريق الذي يعمل عن بُعد 
عن طريق شبكة متلفزة» ويوجد أيضاً قائمة مفصلة بالمهام يعمل 
مدير التزويد على أساسها بإجراء جولة تعليمية للفريق الذي يعمل 
عن بعد حول نظام 18/114. 


يُمضي كل فريق يعمل عن بعد عدة أسابيع في دراسة التمارين 
التي تم إنشاؤها خصيصاً لهم لزيادة اضطلاعهم بالبنية التحتية 
والأدوات والعمليات. ومن ثم ينتقلون إلى زيادة اضطلاعهم حول 
المتطلبات والهيكلية وخطة المشروع. وأما بخصوص الفرق التي 
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تعمل بالفعل» فتتم هذه العملية على الأكثر قبل شهر من استعدادهم 
وجهوزيتهم للبرمجة الفعالة. خلال هذا الشهرء يقوم مدير التزويد 
بمساعدة الفرق التي تعمل عن بُعد في دعم استيعابهم للعمليات 
والنواحي الأخرى للمشروع. حتى هذه اللحظة» لم يواجه الفريق 
المركزي أي حاجة إلى إعادة تدريب أي من الفرق على أي من هذه 
النواحي» ما لم يحدث هناك تغيير كبير على أي من هذه النواحي. 
في هذه الحالة» يقوم الفريق المركزي بتخصيص جزء من وقت أحد 
الاجتماعات الأسبوعية لتوزيع المعلومات الجديدة والمحدثة المتوفرة 
عن نظام 71/111. 


4-4 الوضع الحالي للجهود المبذولة في تطوير نظام 
(غ31511) 


في الوقت الحالي (في الأول من كانون الأول/ ديسمبر 2005) 
تم وضع الأساس لمتطلبات مشروع نظام (16نآ[315). تتوفر في نظام 
ل كافة المكوّنات والروابط والوحدات وعملية النشر وتوزيع 
الهيكلية ونموذج المجال كبير الأهمية للنظام ومواصفات واجهات 
التطبيق (الواجهات المرئية للمكوّنات المعروضة للعامة) والمواصفات 
الأدائية (مخططات متتابعة خلال الواجهات المرثية المعروضة للعامة). 
لقد تم إنشاء هذه الأمور من خلال خطة مشروع متماسكة ومسيطر 
عليها. وقد باشرت فرق العمل في الجامعة البابوية الكاثوليكية في ريو 
غراند دو سول» وجامعة كارنيغي ميلون». وجامعة مونموث. العمل 
فى عمليات البرمجة للمرحلة الأولى. أما فريق جامعة ليميريك فهو 
بيد لبنس وهو ل قد فى الزرض اه عاقيا لطن ولع موف اميت 
وترقع أم اناق درش بجامقة يريك في العمطياة: ال رسحية مسد 
بداية المرحلة الثانية. 
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5-4 الخطوات التالية لمشروع نظام (3151.166) 

بالنظر إلى الهدف الأكبر وهو تنفيذ المشاريع الموزّعة جغرافيا 
بطريقة فعالة ومستمرة» تم على هذا الأساس تحديد خطوات 
مستقبلية ملموسة» وهي : 


© إدراج عملية تقريبية وآلية ليصبح من الممكن توقع المراحل 
المستقبلية والتخطيط لها. 

© إعداد نظام لتتبع المشاكل وتحديد العمليات اللازمة لذلك» 
وتحسين عملية إدارة التغيير. 

© فهم وتوثيق أهمية نظام 178/111 في نجاح الجهود المبذولة في 
مشاريع تطوير البرمجيات الموزّعة المراكزء وكيف يمكن 
إجراء تحسينات على استخدامه. وكيف يمكن الارتقاء به 
من أجل استخدامها بفعالية وكفاءة في المشاريع التجارية 
لتطوير البرمجيات. 

© جمع المعلومات عن طريق شبكة الإنترنت» وتحليل الشبكات 
الاجتماعية والأدوات التي تعمل تلقائياء وإجراء التحليلات 
لتحديد الأمور التي يجب التركيز عليهاء وكذلك تحليل 
الأنماط التجارية التي قد تكون ذات أهمية من أجل فهم 
وتنفيذ ناجح لمشاريع تطوير البرمجيات المورَّعة المراكز. 

© فهم وتنظيم الطريقة التي تؤثر بها الهيكلية وما يتعلق بها على 
الخر ك4 وو العكمن» 


المراجع 


ئءك1200ك/ 


++ 50/111016 120611111©71111718 .[.31 أع] انلو ,5أمعصع 01 
,لزع 1وء 4001502-11 :نذالطا ,دماوم8 


170[ 111 [0 ه50 :071120110115ج 01 07110 كع "لاا آلان) .اتاعء0 ,عل 11015 


349 


110« لاك 01 ©1071 :1771701 115 0710 21101 "200227 [4 ةا آلاء "171167 - 
7 117-11111تاع71 :011لا كلاخ .610 1ل8 لع15دع ]1 


7 

10 27121112 1116ماع اك مواوء0آ عطا عستتراممة» .1 مه50ن8ز1 ,رعمتم مم8 
61 لل :قططاع 2101 1102هل1عع121 320 051105 محدامءءجآ بمعاوزك 
11 ص11 «.102معه1011آ1 امل لقتهة 
.292-67 .مم ,2001 ,3 .مط ,قل .701 :1ع تررععستته كال 

:501721 010531» .110112 2013ممع06آ1 له [0.١‏ وعمطول رطعاوطمع]1 
/حاعتة 1/1 16-20 ,2 .20 ,18 .701 :نهنا 0ك اطاط[ «.أمعمدمماءنعد[ 
مم 

رع1ممع8» .10168 .6) .آ 220 ,لعل 2تطمع51210 “لى .!8 ,.8 .10 بلإترعط 
:50/107 1ط 11 «. ا تاعطاء1017م حم[ ووعء1*0 220 ,221005 1موع 01 
.36-5 .مم ,1994 ,4 .20 ,11 .1701 


كع عل 011/2 


1ه71» .8355 تلاعط ]12 لطتهة اقتابده2 .ل اعتصدجآ ,.جآ وعمتول ,رطعاوطءء1] 

عمال مام ععمعلمعءمءط :ومعماعاك غ2 اماعمطمم1اء7ع0آ عثله 5011 

0 ©76 0071/61 آهنم ةورع 1ر1 2717 عرلا زه كع 71طاءءءه2 «ماءوزم1ط 
.-524 .جزم ,2005 ,.10/! ,01015آ .51 ,17121716611712 ©:01 590/111 


210011 


. < 018 .18لع 0ط 71 .فاعمط //:ماخط > 


330 


الفعل الخاس) عشر 


نظام معالجة البيانات 


1-5 تمهيد 

للحصول على القراءات وتحليلها في بعض الأجهزة كأجهزة قياس 
استهلاك الكهرباء والغاز والماء. وقد تم إنشاء مشروع نظام معالجة 
البيانات 0 فى العام 9. وتم توثيق المشروع ف السنائق 
كدراسة حالة في شركة سيمنز (2002 ,متانحهة2). وتمت عملية 
البرمجة في أربعة مواقع تابعة لشركة سيمنز في ثلاث دول هي 
سويسرا والعانتا ا المتحدة الأميركنة. 6 8 تسويق 
بالموازنة 0 9 ومدى جره والأهداف الوظيفية. 


اليك ان الخو جربا لجع اط نيز ع يك بع بل نيما 
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مكوّنات نظام معالجة البيانات 18852000. وتم تشكيل فريق تصميم 
هيكلي» يتكون من خمسة مهندسين وخليط من خبراء في هذا 
المجال وفي التصميم الهيكلي. وتم تعيين مسؤولٍ عن التصميم وبدأ 
الفريق في التصميم الهيكلي بتحليل احتياجات السوق» وإنشاء 
الشجرة المفاهيمية» وتقصي تقنيات التطوير التي يمكن استخدامهاء 
وإنشاء النماذج. يتكوّن الفريق المركزي من أعضاء من عدة مواقع 
تطوير عملوا في مراحل مبكرة من المشروع وبشكل رئيس في الموقع 
المركزي. وحالما بدأت العمليات البرمجية» عمل المصممون بشكل 
أساسي في مواقعهم الأصلية» مع وجود اجتماعات متكررة في أحد 
المواقع تم وضع خطة زمنية لها ليتم دمج الأنظمة البرمجية الفرعية 
عندما تكون جاهزة. 


2-5 التحليل الشامل 

كإحدى المهام لفريق التصميم الهيكلي. كان أحد أهم العوامل 
التنظيمية المؤثرة التي ظهرت خلال التحليل الشامل هي عامل 
هذه المهارات في التنظيم المركزي لأن المنتجات السابقة كانت 
تعتمد على نظام 117117 ومنشأ على أساس واجهات مستخدم محلية 
ولكن نظام معالجة البيانات 0 اعتمد على نظام وندوز 
(1171201015) ومنشأ على أساس واجهات مستخدم متشعبة. وكما 
يحدث عادة في شركة سيمنزء كان التنظيم المركزي عبارة عن شركة 
ربحية يوجد فيها عدد محدود من فرق العمل التقنية» أقل من اللازم 
لتطوير منتج بحجم نظام معالجة البيانات 12320 وخلال الفترة 
الزمنية المطلوبة. لذلك تم التخطيط للتطوير الشامل للتعامل مع هذا 
العامل المؤثرء بحيث يتم توفير المهارات المطلوبة في ثلاثة مواقع 
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تطوير إضافية تابعة لشركة سيمنز تعمل عن بُعد عن الموقع المركزي. 
وأيضاً تم تطوير مستوى إضافي لوثائق مواصفات التصميم الهيكلي 
بمستوى أقل من التصميم كبير الأهمية. يقوم هذا النظام بتصميم 
المواصفات عن طريق التركيز على وصف الروابط والعلاقات بين 
الأنظمة الفرعية الرئيسة للبنية الهيكلية» وتم توزيع هذه الأنظمة 
الفرعية في مواقع البرمجة التي تعمل عن بُعد. 

أحد العوامل التنظيمية الأخرى هو أن الإدارة أرادت عرض 
المنتج في السوق بأقصى سرعة ممكنة» لأن السوق كانت في حالة 
تغير سريعة» وكان يؤمل أن يتم تسليم المنتج بوظائف محدودة إلى 
المستخدمين المحتملين من أجل جمع تغذية مرتجعة واراء 
المستخدمين حول المنتج. فقد كانت الاستراتيجية المتبعة للتعامل مع 
هذا العامل هي تطوير المنتج بشكل مرحلي باستخدام أسلوب 
التجزيء الزمني بحيث يتم الالتزام بمواعيد الجدول الزمني حتى وإن 
افتقد الإصدار لبعض الخواص. وقد استخدم نظام معالجة البيانات 
0 من ست إلى ثماني مراحل تطوير أسبوعية لكل إصدار 
هندسي. هذه الفترة الزمنية للمراحل مكنت فريق البرمجة من إنتاج 
مجموعة جيدة من الخصائص التي يمكن اختبارها وتقويمها من قبل 
فريق الاختبار. 


تم وصف الكثير من الممارسات المستخدمة في مشروع نظام 
معالجة البيانات 22552000 في هذا الكتاب» وكان ذلك المشروع 
احا وبالتالي أصبح من المراجع الدراسية ل «الممارسات الأفضل»2. 
ومن التعديلات المهمة التي تم إجراؤها منذ تنفيذ هذا المشروع هي 
إنقاص الفترة اللازمة للمراحل من ستة أو ثمانية أسابيع إلى فترة شهر 
واحد تم التخطيط لها بحيث يتم العمل بشكل متزايد. وقد تم 
ملاحظة أن الإصدارات الشهرية للمهام البرمجية جعل المشروع يسير 
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بشكل منتظم وعرض رؤية أفضل للتقدم في سير المشروع بحث يتم 
مراجعة ذلك فى كل شهر. ولا نعتقد أن الفترة الزمنية الشهرية متقاربة 
أكثر من اللازم لتناسب مشاريع التطوير المورّعة لأن مرحلة التطوير 
تتكون من عدة فترات زمنية يستمر العمل فيها لمدة سنة أو أقل. 


5 3 استراتيجيات التصميم 

تحدد الاستراتيجيات المتبعة في عملية التصميم خواص الهيكلية 
والقيود المفروضة عليها وتساعد فى تحديد المخاطر المحتملة 
المسعلتة رتطيق النظاء الويف وكفييةا لمشيل القامل 'لقظاء 
معالجة البيانات 1852000» تم تحديد أربع وغشرين استراتيجية 
تصميمية موجهة للتعامل مع العوامل المؤثرة. وتم استنتاج ستة أمور 
من هذه الاستراتيجيات الأربع والعشرين» وتم استخدامها كمبادئ 
توجيهية للمشروع. وأحد المبادئ التوجيهية الستة هو أن تتم البرمجة 
في عدة مواقع. ونعرض هذا المبدأ مرة أخرى كما باوليش ,طؤتانةه©) 
(2002 في ما يأتي. 


© التطوير في عدة مواقع: وجود نقص في الكفاءات التقنية 
المناسبة في موقع واحد كان من العوامل المؤثرة التي تم التعامل 
معها عن طريق إنشاء أربعة مواقع مختلفة موزّعة في ثلاث دول 
للعمليات البرمجية. ويضع هذا القيود على عملية التصميم لأن توزيع 
المهام يكون أكثر صعوبة حين وجود عدة مواقع» ويجب أيضاً إعداد 
البيئة والأدوات بحيث تناسب وجود مواقع عمل متعددة. 


4-5 هيكلية نظام معالجة البيانات 


تم تصميم الهيكلية لنظام معالجة البيانات 2852000 بحيث 
يمكن إضافة الأنظمة الفرعية إلى الطبقة المنطقية للعمل. وإضافة إلى 
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ذلك» تم اكتساب البيانات بواسطة نظام جزئي تم الحصول عليه من 
منتج آخر لشركة سيمنز ومن ثم تم تعديله. تقوم الأنظمة الفرعية 
بعيلة تاذل السلوناف غلال الحداو كفن قاضذة البيانات المتليارلة: 
الشكل 15 - 1 يوضح ملخصاً للبنية الهيكلية في نظام معالجة البيانات 
50 ه. 


5 5 التخطيط للمشروع 

قو الخطيظ, لتشروع تطويو الترشميات! كي نظام مسعالتمة النانات 
0 كمجموعة متتابعة من إصدارات هندسية تزداد وظائفها 
الخطط الخاصة بالإصدارات أيضاً بشكل يتوافق مع مواعيد معارض 
التجارة الصناعية» بحيث يجب طرح إصدارات جديدة بأحدث 
0*؟*222 تم تحديد وفت ثابت للإصدارات ومراحل للعمل» ومن 
ثم تم تخطيط وظائف كل إصدار في كل مرحلة عمل اعتماداً على 
التقديرات المتزايدة ومتطلبات الاختبار. 


المورّعة. وقد وجدنا أن استخدام النظام نفسه هو من أفضل الوسائل 
الخاصة بالتواصل بين الفرق الموزّعة في المواقع الأربعة. على سبيل 
المثال» بعد إصدار نماذج أولية لأجزاء من نظام معالجة البيانات 
0 أصبح من الممكن تحقيق فهم كامل ومناقشة المتطلبات 
فقط. وقد يكون هذا لأن عمل النظام نفسه يصبح موضوعاً مشتركاً 
للجميع. وتقوم البرمجة المتكررة أيضاً بتشجيع المبرمجين على التعلم 


[مزماء 


السريع والبدء باستخدام تقنيات جديدة لأنهم يكونون حينها بحاجة 
إلى التعلة: بشكل أكبر ليصيهيوا 'قادرية على التظبيق#: حتن :بالنسبة 
إلى الوظائف الجزثية . 

المعالجة 


واجهة سل ١‏ شبكة داخلية وشبكة خارجية 


خادم الشبكة. صفحات الإنترنت 


قواعد العمل 


واجهة قاعدة للبيانات 
قاعدة البيانات شيعا داخلية ان 


الجداول غير المشتركة اح 00 


الشكل 1-15: هيكلية ذات ثلاث مستويات لنظام معالحة البيانات 2000 
٠ )62252000(‏ من ١‏ اعءز0, عفادا 50 ع#1اترعن)-ء تناع 71 ع4 بطكتلبةط .ل اعتصدمل) 


.(2002 ,تإعاوء /لاسموكنتللم ندماده8) اتمنموهرملط1 مع أخذ الموافقات اللازمة. 


6-5 إدارة المشروع 


يعمل في كل موقع من المواقع الأربعة الخاصة بتطوير نظام 
معالجة البيانات 1552000 مدير محلي للمصادر للقيام بالأعمال 
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الإدارية لأعضاء الفريق. ويوجد أيضاً مدير عام لمشروع نظام معالجة 
البيانات 22252000 وأيضاً مديرو مشاريع لكل عملية تطوير 
لمجموعة من مجموعات التطبيقات البرمجية. وبذلك» يكون هناك 
مديرون على المواقع المحلية ومديرون عامون للمشروع مسؤولون 
عن تحقيق أهداف المشروع. فعلى مديري المشروع مناقشة مهام 
العمل الفردية؛ على سبيل المثال» إذا كان مخططاً أن يعمل أحد 
الأفراد على برمجة عدة مجموعات من التطبيقات البرمجية فى نفس 
الوقك# :يعم الجدير العام 'للمشتزوع تإمحاف حلول للأفور الي 
تتعارض مع بعضها بعضاً. 

نقد كان وكيس قن العصيى اميك نتنؤؤلا عن أذ 
القرارات وإيجاد الحلول للأمور المتعارضة تقنياً لمجموعات 
التطبيقات. وكانت هذه الوظيفة تعتبر مهمة في المشروع وتمتلك 
صلاحيات شاملة. في الواقع العملي» تمت مراجعة القرارات التقنية 
المهمة التي أثرت في أهداف المشروع من قبل كل من مديري 
المشروع والمديرين التقنيين قبل أن يتم تطبيقها. 

إن كل نظام فرعي تم تصميمه وتطبيقه في نظام معالجة البيانات 
0 تم وضع أحد المهندسين ليكون مسؤولا عنه. إضافة إلى 
ذلك» تم جمع المصادر اللازمة لتطبيق أحد الأنظمة الفرعية في 
موقع واحد. 

تم تتبع حالة العمل في المشروع خلال الاجتماعات المتلفزة 
الأسبوعية. وتم حث كل عضو من أعضاء الفريق أن يقدم تقريراً 
حول سير العمل البرمجي» وأن يقوم بعرض أي معلومات أو أمور 
أخرى لمشاركتها مع الأعضاء الاخرين. 


يعمل في مشروع نظام معالجة البيانات 1552000 تقريباً عشرون 
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مهندس برمجيات تم تعيينهم خلال ذروة العمليات البرمجية ؛ لذلك 
كان من الممكن أن تقوم الفرق بتقديم تقارير أسبوعية حول سير 
العمل البرمجى خلال الاجتماعات الأسبوعية المتلفزة. 


7-5 دروس مستفادة 

تعامل بعض أعضاء فريق مشروع نظام معالجة البيانات 
0 مع عملية تطوير مواصفات تصميم النظام على أنها غير 
ضرورية» وتأخر بدء العمل في تطبيق المجموعات البرمجية. ولكن 
تمكن أعضاء فريق برمجي جدد يعملون على كل مجموعات 
التطبيقات القديمة والجديدة من استخدام هذه المواصفات بشكل 
ناجح. وكان تجزيء رزم العمل على المواقع الأربعة نقطة مهمة 
وحرجة. وقد لاحظنا أن عملية الدمج للأنظمة الفرعية المختلفة تمت 
بسلاسة مطلقة حين وجود قادة هذه الأنظمة الفرعية في موقع واحد. 

تكون لدينا خبرة جيدة في أسلوب البرمجة التزايدية في مشروع 
نظام معالجة البيانات 2852000. ومن خلال نشر العنوان الإلكتروني 
للموقع الذي تتم فيه عملية احتبار النظام التي تتم فعليا في سويسراء 
استطاع جميع أعضاء الفريق ومديريهم من مراقبة تقدم العمل 
البرمجي كلما تمت إضافة خاصة جديدة. وقد كان هذا عاملا مهما 
في رفع معنويات الفريق» إذ أصبح كل عضو في الفريق مدركاً 
للتقدم السريع الذي تم إنجازه بعد اكتمال مرحلة التصميم كبيرة 
الأهمية» وتمت مباشرة العمليات البرمجية. وقد كانت أول 
الإصدارات الهندسية تطبيق شريحة عامودية فى الهيكلية. وقد ساعد 
هذا في التأكد من صحة الهيكلية ومنح الفريق البرمجي الثقة وزاد 
فهمهم للبنية الهيكلية بحيث يصبحون قادرين على تطبيق إصدارات 
هندسية أخرى في المستقبل. 

بما إننا وضعنا أولويات في الجدول الزمني بخصوص 
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الإصدارات وعمليات تبادل الوظائف كلما دعت الحاجة» استطاع 
الفريق البرمجي أن ينجز الإصدارات في موعدها المحدد. وقد ساعد 
هذا في تكوّن صورة لصدقية الفريق البرمجي من قبل المديرين لأنهم 
كانوا على علم بأن مجموعة جديدة من الوظائف سوف تكون جاهزة 
لتتم عليها عمليات التحقق في التواريخ المخطط لها في بداية العمل. 
لحسن الحظ. تمت المحافظة على جودة عالية للبرمجيات وثبات 
جيد للنظام خلال العمليات البرمجية» ولذلك لم يكن صعباً التوفيق 
بين المحافظة على المواعيد وجودة البرمجيات. 

في بداية المشروع. تم عقد اجتماعات شهرية للمشروع». بشكل 
متناوب في مواقع البرمجة المختلفة. وفي وقت لاحق. تم عقد 
الاجتماعات بشكل رئيس عند دمج الأنظمة الجزئية الرئيسة أو عند 
وجود حاجة للتدريب أو حاجة لتوضيح التفصيلات حول التصميم 
لمهام برمجية جديدة. عقدنا اجتماعات متلفزة أسبوعية للوقوف على 
وضع الجدول الزمني وتوضيح بعض المشاكل العامة التي يجب على 
المبرمجين أن يكونوا مدركين لها. وكإجراء إضافي» قمنا بنشر 
أهداف الاجتماع المتلفزء باستخدام التقنيات التي تعلمناها خلال فترة 
تدريب الفريق وإنشائه للتخطيط للاجتماعات وعقدها. 

تم عقد ورشتي عمل لجميع الفرق في مرحلة مبكرة للمشروع ؛ 
بحيث شعر الجميع بقيمة المشروع. الورشة الأولى كانت تختص في 
عملية بناء الفريق تم عقدها في أحد المواقع البعيدة في سويسرا. 
بالإضافة إلى الإجراءات الاعتيادية لبناء الفريق» تم التعامل مع مهام 
محددة» مثل تطوير عملية قياسية للمشروع. وشملت الورشة 
تخصيصاً لبعض الوقت من أجل أن يتعرف أفراد الفريق على بعضهم 
بعضاً ويتبادلون النقاشات على شكل أزواج حول مشاركتهم واختلاف 
الآراء حول ذلك. 

الورشة الثانية كانت ورشة متعددة الثقافات عقدت في مبنى 
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مدرباً على الثقافات المختلفة فى سويسرا وألمانيا والولايات المتحدة 
الأميركية. .وكان وذ :الفعل على هذه الورشة إيجابيا أيضاك لأنه من 
الواضح أن صبر أعضاء المجموعة كان يزداد كلما زاد تعلمهم 
لثقافات الدول الأخرى. وكان أعضاء الفريق البرمجي قد نشأوا 
وترعرعوا في عشر دول مختلفة» ولكن الورشة ركزت بشكل أساسي 
على الدول الثلاث التي تتمركز فيها مواقع البرمجة. وكان أحد نتائج 
هذه الورشة التركيز على تحديد المهام والوظائف لأفراد الفريق. وكان 
هذا نتيجة إدراك أن هناك ثقافات معينة تثمن العمليات والوظائف 
المحددة بشكل جيد»ء وكذلك المواقع ووضع كل عضو من أعضاء 
الفريق في التنظيم المركزي. ويدعم عقد مثل هذه الاجتماعات فكرتنا 
بأنه يجب تطوير علاقات العمل الشخصية بين الأعضاء المهمين 
للفريق المركزي والمواقع التي تعمل عن بعد لتسهيل عملية التواصل 
حين ظهور أي عائق في عملية التطوير. 

يُمضي أعضاء فريق البرمجة جزءاً كبيراً من وقتهم في عمليات 
التواصل والتفاعل أثناء الاجتماعات؛ لذاء لا بد من فهم الأنماط 
الثقافية المختلفة التي يتم استخدامها. ويميل بعض أعضاء الفريق إلى 
تقديم تقرير متفائل عن تقدم العمل. لكن قد يشعر بعضهم بعدم 
الراحة أو بتخوف بسبب مناقشة وسائل تقنية مختلفة من قبل المؤيدين 
لكل وسيلة. وقد شارك بعضهم في عملية التواصل وبعضهم لم 
إلى فريق البرمجة هو طرح منتج عالي الجودة في الأسواق وفي 
الوقت المحدد ضمن الموازنة الموضوعة. لذلك» يقوم منسقو 
الاجتماعات أو مديرو الفريق» الذين أدركوا الاختلافات الثقافية 
وكانوا قادرين على تحفيز نتائج أفضل لكل فرد من المهندسين» 
بمساهمة جيدة للمشروع. 
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قد تؤثر الاختلافات الثقافية في القيم مثل الالتزام بالمواعيد 
والإتقان وأخلاقيات العمل والعمل الجماعى والجودة والتفاعل فى 
القرارات المتعلقة بالمشروع. وقد تحسن هذه الاختلافات عملية سير 
المشروع وقد تعيقها. وبالطبع» تعتبر الإجازات من إحدى أهم 
المشاكل المتعلقة 0 الثقافية التي 1 مدير 0 ومن 
مفاجئ في المواقع ا ل 
في التواصل خلال العمل اليومي. وفي حالتنا هذه هناك فارق 
مقداره ست ساعات فى التوقيت. 


فكرة مفيدة: 

شارك في برامج جح السفر دائماً. 

إذا تم تعيبنك في أحد مشاريع التطوير الموزّعة» فلا بد 
من أنك ستسافر إلى بعض المواقع التي تعمل عن بُعد. 
إن السفر بهدف التواصل وجهاً لوجه أمر ضروري لنجاح 
مشاريع التطوير الموزع» ومن أجل تشجيع مديري 
لمشاريع لتخصيص موازنة مناسبة للسفر. ومع ذلك» قد 
تعانى فى كثير من الأحيان من اضطراب نتيجة الرحللات 
لعريةه ويالنالي لق فل كنانة عالية عندما توجّد في 
لمواقع التي تعمل عن بُعد. لذاء شارك في برامج السفر 
3-0 وافعل ما بوسعك لتكون هذه الرحلات مريحة 
لتحافظ على كفاءتك في العمل بعد الوصول. 


8-5 الملخص 
على الرغم من الجهود الحثيثة التي بُذلت للتواصل ب بين المواقع 
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الأربعة والتركيز على الوثائق الخاصة بالتصميم مع وجود واجهات 
معدة بشكل جيد» وجدنا أن التطوير الموزع كان بشكل واضح أكثر 
صعوبة من التطوير في موقع واحد. وكان هذا نتيجة وجود خلل في 
عملية التواصل من وقت إلى اخر وذلك بسبب اختلاف في مواعيد 
الإجازات والعطل الرسمية من دولة إلى أخرى» 507 فى 
التوقيت» وأيضاً بسبب أعطال في الحواسيب أو الشبكات في بعض 
الأحجاف عانم سجيان المكاله زؤااتى برحب سواله لين الرملاه 
الموجودين في أوروبا خلال ساعات المساء من قبل الفريق الذي 
يعمل في الولايات المتحدة خلال ساعات عملهم. يجب عليهم 
الانتظار حتى اليوم التالي للحصول على الإجابة. ولتدارك الأمور غير 
المتوقعة» يقوم أعضاء الفريق عادة بالتواصل مع زملائهم في الفرق 
الموجودة في دول أخرى عن طريق هاتف المنزل» وتمت إعادة 
برمخة النظاه. كل يوخ تقريباً في عدة مواقع باستخدام أحدث شيفرة 
متوفرة. كما تم الاهتمام بالتدريب المتعلق بالتقنيات وبناء الفريق 
والتدريب المتعلق بتعدد ثقافات أعضاء الفريق البرمجي. 

تم تصميم هيكلية نظام معالجة البيانات 25252000 ليكون مرناً 
وقادراً على التعامل مع أنواع كثيرة من التطبيقات. وكان ذلك تصميماً 
أولياً من حيث المتطلبات. وقد ساعد التنوع أعضاء الفريق البرمجي 
في تحقيق تصميم مرن من حيث المهارات والخبرات. في هذا 
المشروع» أضافت مساهمة فرق البرمجة الموزّعة في عدة دول 
جاذية. إن قوفن المتمهات الغالمة: 


المر اجع 
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نظام المعلومات المالية 


حققت شركة الخدمات المالية (581) نجاحاً كبيراً فى توفير 
الاوك الروميفة:لالعيواك «المتوافة دوا لكر قن يرون الؤنطي ترما 
تغيّر تدريجي في هذا النوع من الخدمات. فقد اندمجت بعض البنوك 
غير المستقلة والرهن العقاري وشركات الاستثمار ومزودو خدمات 
التأمين جميعاً بشكل تدريجي ليشكلوا شبكة كبيرة ومتكاملة من 
مزودي الخدمات المالية. يمكن الآن للعملاء أن يتوجهوا إلى أي 
مؤسسة ضمن شبكة مالية للحصول على خدمة مالية معينة» ويتم 
عرض خدمات ومنتجات مالية أخرى عليهم بكل سهولة. وما إِنْ 
يفتحوا حسابا في مؤسسة واحدة» حتى يكون هناك حاجة لفتح 
حسابات منفصلة في مؤسسات أخرى ضمن نفس الشبكة. ويعمل 
هذا الحساب كمستودع واحد يخدم المحفظة المالية الكلية للعميل» 
ويصبح من الممكن أن يستلم العميل بياناً مالي واحدا بدلا من استلام 
عدة بيانات يمثل كل منها خدمة مصرفية واحدة. 

وجدت شركة الخدمات المالية أن هذا يمثل فرصة تجارية 
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سانحة لإنتاج حلول برمجية جديدة ونظام معلومات مالي (552000) 
واحد يتيح تنفيذ عمليات دمج وتدفق للمعلومات خلال جميع 
المشازيع بشكل سلس. هذا وقداشكلت الشركة فريقا للبخث 
والتطوير (84:1) يتكون من خبراء في هذا المجال ومهندسي 
برمجيات للبدء على الفور بتنفيذ هذا المنتج. 


1-6 متطلبات المشروع الجديد 


يعمل الخبراء في هذا المجال ومهندسو البرمجيات ضمن فريق 
يعرف الكثير عن النموذج القديم الخاص بالبنوك» واكتسبوا خبراتهم 
من النظام المستقل الذي قامت الشركة ببنائه لخدمة البنوك المستقلة 
وراهني العقارات والشركات الاستثمارية ومزوّدي خدمات التأمين. 
وقد تطلعوا إلى الفرصة الجديدة على أنها ستمثل عملية إنتاج عمل 
متكامل يستطيع نقل المعلومات الخاصة بالعميل وجعلها متوفرة في 
هذه المشاريع بسهولة. ونظراً إلى اختلاف كل هيئة مالية عن الهيئات 
الأخرى فى طريقة انتقال المعلومات وعرضها والدخول إليهاء كان 
من الضروري إنشاء آلية'مرنة:قادرة غلئى التكيف من أجل العمليات 
التجارية ومواصفات واجهة التطبيق. 

لم تقم الشركة بإحضار خبراء في هذا المجال ممن يمتلكون 
خبرة في نموذج العمل التجاري الجديد لاعتقادهم بأنهم يمتلكون 
معرفة عميقة في مجال المنتج. واعتبر فريق المشروع أن المتطلبات 
الوظيفية متقاربة لحد بعيد باستثناء القليل من الوظائف الخاصة 
بالمنتج؛ أي إنه يجب فقط أن تكون الطريقة والمكان الذي يتم فيه 
استخدام هذه الوظائف مرتين. 

ونظرا إلى أن القريق الذي ومكوان »من اخبراء وشه نسي 
البرمجيات كان صغيراً جداً لم يعتبر أنه من الضروري إنشاء أي 
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متطلبات رسمية ونموذج لمجال العمل. وتم استخدام أسلوب 
العصف الذهني للمعلومات كآلية مبدئية للوصول إلى جزئيات جميع 
العمل المطلوب. 


نتج من اتباع أسلوب الترميم وثقافة العمل التي انتهجتها الشركة 
مجموعة من العواقب. الأول: على الرغم من أن رؤية الشركة 
والفرصة المتاحة في السوق كانتا رائعتين» غير أنه لم يكن كافياً إنجاز 
نظام مرن ومتكامل فقط. كان هناك الكثير من القطاعات في السوق 
حيث تتراوح بين المؤسسات الصغيرة والكبيرة» وقد كان من 
الضروري أن يقيس النظام احتياجاتهم. وقد كانت مكاتب بعض 
المؤسسات الكبيرة مورّعة بشكل كبير وتختلف في ما بينها في نظام 
التوقيت؛ وكان على النظام أن يأخذ بعين الاعتبار هذا الانتشار عندما 
يتم توزيعه في منطقة العمل. ولم تحتج المؤسسات الصغيرة إلى 
جميع إمكانيات النظام الجديد؛ واحتاج النظام إلى إعادة تجزئته إلى 
مجموعة من المكوّنات توفْر مرونة في عملية توزيع النظام بأسلوب 
تدريجي وفق الحاجة. ولم يرغب معظم العملاء في تحمل مسؤولية 
إدارة النظام الخاص بهم؛ إذ كان يجب أن يتم توزيع النظام والتعامل 
معه بطريقة فعالة من حيث التكلفة من مركز المعلومات الخاص 
بالشركة. وكان هناك مجموعة من العمليات التجارية التى تعتبر مهمة 
وحرجة بالنسبة إلى العملاء؛ وكان على النظام بكو متدرا 
للاستخدام في أي وقت بشكل مؤكد. 


تمثل العيب الثاني والأكثر أهمية بعدم جمع المعلومات المتعلقة 
التواصل في ما بينهم. وكان نتيجة ذلك هو الشعور بنقص حاد في 
المعلومات. وفى النهاية امتلكت شركة متعددة الجنسيات 1/1210 


شركة الخدمات المالية. 
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رأت الشركة متعددة الجنسيات أن الاستراتيجية الأولية التى 
اتبعتها شركة الخدمات المالية تعتبر مكملاً مهما لمنتجاتها وخدماتها 
التحالة» جا متيلينا قادرة عا اناد خلو ل متكائلة الاسساجات 
المؤسسات المالية المنتشرة حول العالم. إضافة إلى ذلك» ستتيح لهم 
شركة الخدمات المالية فرصة امتلاك حصة مهمة من السوق فى 
أميركا الشمالية. 

حالما تمت عملية الامتلاك» رغبت الشركة متعددة الجنسيات 
بتوسيع مجال عمل نظام المعلومات المالية (582000)» إذ أرادت أن 
تجعل منه نظاما دوليا. وكان انطباع الشركة متعددة الجنسيات بأن 
تصور شركة الخدمات المالية للمرونة سوف يمنحهم القدرة على 

كنا وفزك) الشركة اشتعدوة المكسياه لهذا العمل مجدوعة دولنة 
من مهندسي البرمجيات» إذ اعتّقد أن ذلك سوف يجعلهم قادرين 
السوق. وبالإضافة إلى وجود الفرق في المواقع المختلفة داخل 
الولايات المتحدة فى الوقت الحالى» شكلت الشركة متعددة 
والسويد وألمانيا والمملكة الوتتخلة والهند. وقد تم تجزيء 
المتطلبات» كل وفق وظيفتهاء إلن وحدات متعددة وتوزيعها حول 
العالم لإجراء العمليات البرمجية. ونفذ الخبراء في هذا الموضوع 
الموجودون في الولايات المتحدة عمليات التحليل والتصميم بينما 
تمت العمليات البرمجية في المواقع التي تعمل عن بُعد في دول 
أخرى. وبعد انتهاء العمليات البرمجية على الوحدات أعيدت إلى 
الولايات المتحدة لإجراء عمليات الدمج. 
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ومع ذلك» لم يكن هناك مجموعة من المتطلبات الرسمية أو 
النماذج التي تقيس بشكل منهجي تغير وتوسع الحلول الخاصة بعمل 
نظام المعلومات المالية (552000). ونتيجة لعدم وجود هذين 
الأمرين» أنشأت فرق العمل لمشروع نظام المعلومات المالية 
(552000) بحلا مرناً بدوسة كييرة بنحيت يتبعل من الممكن تطبيق أي 
مواصفات للعمليات الخاصة بأي عمل تجاري وكذلك عرض 
المعلومات المتعلقة بهذا العمل على واجهة التطبيق الخاصة 
بالمستخدم. وقد كان على الفرق أن تنشئ منفذاً للبرمجيات حسب 
طبيعة هذه المواصفات» إذ كلما أصبحت المواصفات أكثر تعقيداء 
ازداد تعقيد منفذ البرمجيات أيضاً. وفي النهاية كان هذا العمل 
لباه مكلا سو حي اللكدان: والمعالهة والصيانة وضبلنات 
الدعم؛ كما إن أداء المنتج كان ضعيفاً. 


وفي الوقت نفسه. استمرت فرق العمل في المشروع بالنمو 
لتسريع العمليات البرمجية. وقد أدى هذا إلى وجود مسارات طويلة 
للتواصل بين الموقع المركزي في الولايات المتحدة ومواقع البرمجة 
التي تعمل عن بُعد. ولذلك» واجه المسؤولون عن ارو صعوبة 
كبيرة في تكوين فهم مشترك لهذه الأمور وتنسيق أنشطة العمل بين 
فرق المشروع. 

كانت الشركة متعددة الجنسيات متحمسة للتقدم في العمل» 
واعتقدت أن بإمكانها البدء في عملية تطوير للمشروع عن طريق جمع 
المعرفة في مجال نظام المعلومات المالية (552000) والمتطلبات 
الخاصة به. فقد تقوم عملية الحصول على المعرفة بتيسير عمليات 
التواصل وتساعد في المهام الصعبة المتعلقة بنقل المعلومات ذات 
الغلاقة: إلى. الفرق: الى تعمل عن يُعذاء :وهنا واجهت' الشركة متعددة 
الجنسيات عقبة ار وتمثلت خيبة أمل الشركة في أنه كان هناك 
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القليل من الوثائق التي توضح طريقة جمع العمل في مشروع نظام 
المعلومات المالية (552000). كما وُجد أيضاً أن فريق مشروع نظام 
المعلومات المالية (152000) كان في الحقيقة عبارة عن عدد من 
المجموعات المختلفة الصغيرة يركز كل منها عمله في مجال الخبرة 
لديه مع عدم وجود أي تواصل بينهم في الأغلب. وجعل هذا كل 
فريق يعتقد أن وظيفة المشروع تستهدف فقط المجال الذي يعمل فيه 
دون أدنى فكرة عن الآلية التي سوف يتم من خلالها دمج أجزاء 
العمل لتكون مشروعا واحدا وهو نظام المعلومات المالية (5852000). 
والآأسوأ من ذلك» استخدم كل فريق مجموعة من التقنيات المفضلة 
لديه لإنجاز العمل الخاص به. 


6- 3 الهيكلية 

بينما كانت الشركة متعددة الجنسيات تحاول فهم نظام 
المعلومات المالية (552000) وجعله يعمل» خطرت لنائب رئيس 
البحث والتطوير فكرة؛ «لماذا لا نقوم بجمع مكوّنات التطبيق الحالي 
التي يمكن إعادة استخدامها وتكوين النظام تدريجياً بتركيب مكوّن 
واحد في كل مرة؟» وتم تعيين مسؤول عن الهيكلية وبدأت الجهود 
تنصبُ في تحديد أقل مجموعة من المكوّنات التي يجب أن يحتويها 
النظام بحيث يمكن بيعها في السوق. 


طرح مسؤول الهيكلية على فريق عمل إدارة المشروع هذا 
السؤال» وهو «ما هي أقل مجموعة مكوّنات يمكن الحصول عليها 
بحيث تكون قابلة للبيع؟»؛ وقد فوجئ بأن فريق عمل إدارة المشروع 
لم يشارك نهائيا في مشروع نظام المعلومات المالية (552000). 
وكانت الاستراتيجية الوحيدة لدى هذا الفريق هي بيع النظام الجديد 
عندما يكون جاهزاً إلى عملائهم المعروفين. ولم يكن هناك أي 
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اهتمام بالمؤسسات الصغيرة لآن شركة الخدمات المالية» التي تم 
تملكهاء كانت تبيع منتجاتها للمؤسسات الكبيرة فقط. أعثبر نظام 
المعلومات المالية (552000) نظاما متكاملاء ولذلك لم يضع فريق 
العمل بعين الاعتبار أن يتم التسليم للنظام بشكل تدريجي عن طريق 
بيع أجزاء منه فقط في كل مرة. 

في الوقت الذي أصيبت به الشركة متعددة الجنسيات بخيبة 
الأمل من الأخبار التي تلقتها من مسؤول الهيكلية» لم تكن الشركة 
تنوي الاستسلام بعد. فربما ببعض الحظ. يمكن أن يكون هناك 
أصول مشتركة بين مجموعة حزم الوظائف الكلية لنظام المعلومات 
المالية (852000). وقد يشكل هذا نقطة بداية جيدة» في حال توقره. 

قام مسؤول الهيكلية بدراسة مجموعة البحث والتطوير للوصول 
إلى فهم الهيكلية. واعخير كل فريق صعيي اسل مشروع نظام 
المعلومات المالية (852000) فريقا افتراضيا للبحث والتطوير بحيث 
أوجدوا الحلول للجزء الخاص بهم من العمل باستخدام نماذجهم 
الخاصة وتقنيتهم المفضلة. وكانت أفضل الوثائق التي حصل عليها 
مسؤول الهيكلية مجموعة من شرائح العرض ()مذه2 0:*68©) . 
وبالتالي» تحولت الجهود من أجل تحديد أصول مشتركة إلى 
عمليات لتوثيق الهيكلية. 

لم تكن الشركة متعددة الجنسيات مستعدة للاستسلام بعدء 
فطلبت الشركة من مسؤول الهيكلية لديها إكمال عملية توثيق الهيكلية 
للوصول إلى نتيجة في عملية توحيد الجهود المشتتة لعمل مجموعة 
البحث والتطوير للوصول إلى نظام معلومات مالية (552000) 
متكامل. وبعد عدة شهور من العمل الشاق» ظهرت أخبار أخرى 
مخيبة للآمال» فقد جمع كل فريق من مجالات التخصص الأجزاء 
الخاصة بحلول هذا المجال الخاص به معا في نموذج بيانات خاص 
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مستقل» أي إنه تم تمثيل الأمور والمفاهيم المتشابهة بطرق مختلفة 
في كل نموذج من نماذج البيانات. ولم يكن هناك فهمٌ مشتركِ أو 
توافق لأي من المفاهيم» حتى بالنسبة إلى الأمور الأساسية كحساب 
العميل. وأدركت الشركة متعددة الجنسيات الآن أن لديها مشكلة 
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ا 


4-6 إعادة هيكلة المؤسسة 

لاحظت الشركة متعددة الجنسيات أن التزام أعضاء فريق عمل 
مشروع نظام المعلومات المالية (552000) كان ضعيفا في ما يتعلق 
بتعاونهم مع بعضهم بعضاًء ما أدى إلى أن يصبح مشروع نظام 
المعلومات المالية (852000) نظاماً وهمياًء إذ إن أعضاءه ينتمون إلى 
أصول تنظيمية مختلفة» ويمثلون مجال العمل الخاص بهم. فقد كانوا 
جميعاً يخدمون مصالح التنظيم الذي ينتمون إليهء لكن بوجود حافز 
ضعيف جداً للعمل من أجل رؤية مشتركة. ونظراً إلى أنه لم يكن 
هناك أي توضيح للرؤية» كوّن الجميع فهماً جزئياً وغير متماسك عن 
فكرة مشروع نظام المعلومات المالية. وكان هناك حاجة لهيكل 
تنظيمي جديد. 

فى البداية» قامت الشركة متعددة الجنسيات بالتأكد من أن فريق 
عمل إدارة المشروع قد قام بجهود مناسبة وكافية في عملية تحليل 
السوق. فقد قام الفريق بتحديد المنتجات المناسبة لشرائح مختلفة من 
السوق وبأقل مجموعة من مكوّنات نظام المعلومات المالية 
(752000) التي يمكن بيعها. وقام أيضاً بتحديد التطويرات المتزايدة 
التي ستُجرى على أقل مجموعة من المكوّنات للوصول إلى حل 
متكامل لنظام المعلومات المالية (5852000). 

أنشأت الشركة كذلك مجموعة استراتيجية ومستقلة لعمليات 
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التصميم الهيكلي تتكون من الخبراء المهمين في هذا المجال 
ومهندسي برمجيات يترأسهم مدير عمليات البحث والتطوير. وتم 
تكليف هذه المجموعة بالحصول على تصميم هيكلي عام وموثق 
بشكل جيد لجميع الأجزاء التي تتكون منها مجموعة المنتج لنظام 
المعلومات المالية (582000). وكان هدف الهيكلية هذه تحديد 
الأصول المشتركة لجميع أجزاء مجموعة المنتج» وكانت وظيفة 
المجموعة إدارة عمليات البرمجة التي يقومون بها. 


تم إنشاء مجموعات منفصلة لتعمل كل منها في مجموعة فردية 
من مجموعات نظام المعلومات المالية (552000). ويترأس كل 
مجموعة من هذه المجموعات مدير للمنتج يقوم بالإشراف على 
عمليات التحليل والتصميم للجزء الخاص من مجموعة وظائف 
المنتج. وتم تقسيم الوظائف إلى مجموعة من المكونات الصغيرة 
يمكن التحكم بهاء ومحددة بشكل جيد بحيث يمكن برمجتها في 
نفس الوقت بواسطة فرق من مهندسي البرمجيات التابعين لمنظمات 
الشركة متعددة الجنسيات المورّعة حول العالم. 


كانت عملية دمج أجزاء المنتج لإيجاد حلول للشرائح المختلفة 


الهيكلي. 


5-6 إنجاز التكامل 


لم يكن فريق مشروع نظام المعلومات المالية (552000) موزعاً 
وفق مجالات التخصص فقطء بل كان نموذج البرمجة باستخدام 
الكائن (160م0:16-]ءهو[0) غير مألوف لديه أيضاً. وأدى ذلك للوقوع 
في العديد من المشاكل. فقام الفريق باتباع فكرة تحليل الكائن 
ديج قي جد وميك عن الطدات لكر على 
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مكوّنات ذات وجهات محددة بشكل جيدء لذلك قام بإخفاء هذه 
الطبقات عن العالم الخارجي. وأدى ذلك إلى عمليات اقتران وترابط 
موسعة بين معظم الطبقات» منتجا حلا برمجيا جامدا غير مرن وهش 
أيضاً. ونتج من عدم وجود وحدات برمجية صعوبة في إنشاء 
مجموعات من وظائف المنتج يمكن بيعها في السوق لتعمل كمنتج 
يؤدي وظائف كاملة. 

نتيجة تجزيء مشروع نظام المعلومات المالية (552000) وفقاً 
لتعالات التقصصن :وطيستها المساشكة» كلورت دياك التسرعة 
الاستراتيجية لعمليات التصميم الهيكلي المكوّنة حديثاً. وركز كل 
مجال من مجالات التخصص على مجموعة من الوحدات كانت 
كبيرة ليتم التعامل معها في مشروع واحد. ويجب أن يتم التأكد من 
أن الطريق الذي اتبعته المجموعة لإنهاء العمل بهذه التجزئة وإنشاء 
وحدات للحلول يمكن التحكم بها بشكل سهلء» ليس فقط ليلاقي 
دعماً من جميع الأطراف» بل لجعل إنشاء رؤية مشتركة للبنية 
الهيكلية أمراً ممكناً أيضاً. 

قررت المجموعة استخدام النسخة المعيارية من برمجية 
(1288). وتم اعتماد هذا الاختيار لعدة أسباب: أولاء اعتقدت 
المجموعة أن استخدام مجموعة معيارية سترحب به التنظيمات 
المختلفة التي تعمل على المنتج والتي كانت تشارك سابقا في 
النقاشات التي تدور حول اختيار الهيكلية الأفضل. وتم قضاء قدر 
كبير من الوقت في عرض الأسباب التي جعلتهم يقومون بهذا 
الاختيار. 

اما رأت المجموعة أنه من الأفضل استخدام الطاقات 
اليوضيرةة أصلذ فى القدركة للعهل مات الأيون' الأساسيةء:والنن 
تتمثل في إيجاد لمحلل للمجال المالي والجسن جات ام نس 
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للعمليات البرمجية على المنتج لأنه من السهل الحصول على مثل 
هذه الأنظمة في السوق. وسوف يجعل ذلك الشركة تركز على 
الإبداع وتطوير منتجات جديدة وطرحها في السوق خلال وقت 


الغ سيكون من المفيد في مشاريع التطوير الموزّعة بشكل 
واسع» والتي يتم فيها تكوين مجموعات برمجية من مختلف دول 
العالم» أن يكون الاختيار معيارياً لأنه سوف يضمن وجود فهم 
مشتركٌ للبنية الهيكلية بشكل أسرع. على الأقل بالنسبة إلى جوانب 
برمجية (12818) تكون معيارية للجميع بحيث يمكن الحد بشكل 
ملحوظ من المقنابلات المباشرة» وبالتالي» من كلقة السفر حول 
الخاليده ١‏ 

أخيراًء يمكن للفرق التي تعمل على المنتج أن تستخدم نماذج 
برمجية (1281) في عمليات تصميم المنتج وبرمجته. وقد يكون هناك 
بالطبع حاجة لبعض العمليات الإضافية لضمان حلول للوحدات تكون 
القدرة على التحكم بها أكبر. 


6-6 دروس مستفادة 

كان أكثر الأمور التى واجهت الشركة متعددة الجنسيات أهمية» 
نوها يناكة. شرع الحديات انان عه وشرة ضيليات ترثن 
جيدة للمتطلبات ونموذج مجال العمل. ونتيجة لعدم إنشاء هذه المهام 
ظهرت مشكلتان رئيستان: الأولى. أغفلت شركة الخدمات المالية 
كلياً نقطتين تتعلقان بالجودة حين وضع النماذج الخاصة بأجزاء 
المنتج» وهما القدرة على التغيير والقابلية على التوسع. وعلى الرغم 
من أن الحلول المتعلقة بنظام المعلومات المالية (552000) مرنة 
وقادرة على التكيف» غير أن مرونتها وقدرتها على التكيف كانت 
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محدودة فى أسواق أميركا الشمالية. وقد واجهت الشركة متعددة 
الجنسيات وقتاً عصيباً في تجربة الطريقة التي يمكن من خلالها 
توسيع مجال عمل هذا النظام ليصبح مناسباً للعمل في الأسواق 
العالمية. أما المشكلة الثانية والأكثر أهمية من ناحية التطوير الموزع» 
فلم يكن من الواضح كيف يمكن إتمام المهمة الصعبة المتعلقة بنقل 
المعرفة إلى المواقع التي تعمل عن بُعد مع عدم وجود هذه المهام. 
إضافة إلى ما تقدمء لم يكن لنظام المعلومات المالية (1552000) 
توثيق جيد لهيكليته. وفي الحقيقة. لم يكن هناك هيكلية واحدة؛ بل 
نظام المعلومات المالية (552000). كما افتقر النظام إلى تصميم 
للوحدات». ما جعل من الصعب فصل الأصول الأساسية العامة 
الموجودة في جميع أجزاء المنتج. وأدى ذلك أيضاً إلى صعوبة عملية 
إنشاء مجموعة من المكوّنات ينتج عنها منتحٌ يعمل بشكل كامل 
ومناسب لجميع المؤسسات المالية من الصغيرة إلى الكبيرة. ونتجح من 
ذلك أيضاً عدم قدرة الشركة متعددة الجنسيات على امتلاك استراتيجية 
يمكن بواسطتها إنشاء الحلول بطريقة تدريجية ومتزايدة عن طريق 
إضافة المكوّنات بشكل مستمر على شكل مراحل. أما أكثر التأثيرات 
أهمية في عمليات التطوير المورّعة فكان عدم وجودة توثيق للهيكلية 
و ل ل سن بين الفرق 
العمليات البرمجية لنظام المعلومات المالية (552000) وحسب» بل 


لم تكن الهيكلية التي اتبعتها الشركة المتعلقة بجهود البحث 
والتطوير لنظام المعلومات المالية (892000) كافية أيضاً. وكان فريق 
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البحث والتطوير افتراضياً ولم يكن لديه حافز لتحقيق التصور للحلول 
الجديدة. وكان أعضاء الفرق المختلفة منحازين لصالح منظمتهم 
الأم» وأدى هذا إلى تكوّن فرق صغيرة تعمل في المشروع منغلقة 
حول العمل في مجال تخصصهم نتج عنه ما كان يجب أن يتجنبه 
نظام المعلومات المالية (5852000)» وهو إنشاء أنظمة مستقلة غير 
مترابطة. وأصبح الأمر أكثر سوءاً كلما زاد عدد أعضاء الفريق الذي 
يعمل فى مجال تخصصه. وأصبحت مسارات التواصل بين الفرق 
طويلة جداء -ما صشبه :من :عملياث تفيق الأنشطة بين الفرق وإنيجاد 


7-6 الملخص 

في حالة نظام المعلومات المالية (552000)» أدى الحجم الكبير 
لكل مكوّن من المكوّنات والحجم الكبير لعدد أعضاء الفرق التي 
تعمل في حل مجالات التخصص والحجم الهائل للمشروع بأكمله 
إلى ظهور تعقيدات في عمليات التطوير المورّعة. إضافة إلى ذلك» 
أدى عدم وجود عمليات توثيق المتطلبات والهيكلية إلى وجود 
صعوبة في تكوين تصور عام ونقل هذا التصور عن مهندسي 
الخدمات المالية. عززت هذه الدراسة للحالة فكرتنا بأن المشاريع 
الصغيرة تكون عادة أفضل. وعلى كل حال» تتطلب الاحتياجات 
الجديدة للشركة إلى منتج نظام المعلومات المالية (1552000) ضخم 
ومتعدد المتغيرات» ما أدى إلى ظهور تعقيدات عديدة. ويقوم الفريق 
حالياً بإعادة تحديد الهيكلية» ويقوم باختبار طرق لإعادة تشكيل 
الصيغة البرمجية بحيث يتم تجزيئها إلى مكوّنات أصغر يمكن دمجها 
في نظام العمل الجديد. 
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نظام إدارة المباني الآالي 


نظام إدارة المباني الآلي (845) هو نظام لإدارة أجهزة المراقبة 


والتحكم بها ضمن أحد المباني أو في محيط مجموعة من المباني. 
ويستخدم نظام إدارة المباني الآلي في إدارة مختلف تطبيقات العمل 


التلقائية ضمن المبنى كالتدفئة والتهوئة والتكييف والأمن والحريق 
والتحكم في الدخول والتطفل. 


1-7 تمهيد 
تم إنشاء الوثائق الخاصة بمشروع نظام إدارة المباني الآلي 
بواسطة هيرسليب (2005 ,اء1و:116). وقد تمت عمليات البرمجة فى 
وألمانيا وإيطاليا وأستراليا وسلوفاكيا والهند والولايات المتحدة. 
تصف هذه الدراسة الممارسات التى انبعت خلال مرحلتى البدء 
والتطوير لمشروع نظام إدارة المباني الآلي. وخلال مرحلة التحضيرء 
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تم تشكيل فريق صغير لتصميم الهيكلية يتكون من مصممين من 
مواقع مختلفة. وقد عمل الفريق في الموقع المركزي الموجود في 
الولايات المتحدة وفقاً لبرنامج زمني محددء يتضمن العمل لثلاثة 
أسابيع في الموقع المركزي» ومن ثم أسبوعين في مواقعهم الأصلية. 
وقد تم نقل المصمم الموجود في أستراليا إلى الولايات المتحدة 
الأميركية حتى انتهاء فترة مرحلة التحضير. وقد قام فريق المصممين 
بإنجاز عمليات التحليل الشامل وتحليل المتطلبات ذات الأهمية 
الكبيرة؛ كما أنشأوا شجرة المفاهيم وقاموا بمراجعة الهيكلية في نهاية 
للجهد الذي تحتاجه العمليات البرمجية للمشروع والوقت الزمني 
اللازم لإتمامه وفقاً للخريطة المفاهيمية التي تم إعدادها. 


خلال مرحلة التطويرء تم زيادة حجم الفريق لإنجاز متطلبات 
واجهة التطبيق وتحديد العملية وعملية إنشاء النماذج. وخلال هذه 
المرحلة» تم استخدام أسلوب «الفريق الافتراضي» بشكل متزايد» 
ويقومون بحضور الاجتماعات الدورية في المواقع المختلفة التي تم 
تحديد مواعيدها مسبقاً. على سبيل المثال» يجتمع فريق إدارة 
البرنامج شهرياًء وهو في حالة تنقل دائمة بين المواقع في سويسرا 
والولايات المتحدة الأميركية. وقد تم نقل فريق العمل المكوّن من 
المواقع الخارجية والمواقع التي من المتوقع أن تتم فيها معظم 
المتحدة الأميركية حيث باشروا في أنشطة إنشاء النماذج» وتم 
تدريبهم على الهيكلية وعلى مجال العمل التجاري عن طريق فريق 
التصميم. 
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2-7 التحليل الشامل 

تم إنجاز التحليل الشامل في مشروع نظام إدارة المباني الآلي 
كمهمة من مهام فريق التصميم. وكان أحد العوامل التنظيمية المهمة 
والمؤثرة التى برزت خلال عمليات التحليل الشامل أن هناك حاجة 
إلى فريق عمل برمجي لتنفيذ نظام إدارة المباني الآلى في الوقت 
المحدد أكبر من فريق العمل الموجود حالياً. وعلى الرغم من وجود 
العديد من المواقع المهتمة بالمشاركة في العمليات البرمجية لنظام 
أتمقة المباني ؛ غير أنه مع ذلك» وحتى لو اجتمع جميع مهندسي 
البرمجيات من كافة المواقع» فإنهم لن يكونوا كافين لإنجاز هذا 
العمل. ومرد هذا النقص في فريق العمل كان بشكل أساسي نتيجة 
صعوبة تحرير فريق العمل الذي يعمل في الوقت الحالي في مشاريع 
مُدِرّة للدخل باستخدام منتجات سابقة. إضافة إلى ذلك» كان هناك 
عامل مؤثر في سرعة طرح المنتج في الأسواق نتج منه جعل حجم 
فريق البرمجة أكبر من حجمه مقارنة بما كان عليه في مشاريع برمجة 
سابقة. لذلك» تم تحديد استراتيجية المشروع مبكراً بأنه سيكون من 

يتطلب نظام إدارة المباني الآلي دمج التطبيقات ذات المجالات 
المختلفة لتعمل كمحطة عمل واحدة. ونظراً إلى أن هذه المجالات 
قد نفذت كوحدة تخصصية مركزية بين المواقع البرمجية في الشركة» 
فقد نتجح من ذلك تعديل استراتيجية المشروع للاستفادة من الخبرات 
في هذا المجال الموجودة في مواقع الشركة الموزّعة. لذلك» أصبح 
من المعروف مقدماً أنه سيكون هناك حاجة إلى فريق عمل من 
المواقع البرمجية المختلفة التابعة لشركة سيمنز لتنفيذ نظام إدارة 
المبانى الآلى. 
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المباني الآلى في هذا الكتاب» خصوصاً استخدام مدير التزويد 
للمساعدة في التعامل مع المصادر الموجودة في مواقع البرمجة التي 
تعمل عن بُعد. هذاء وبما إن العمل في المشروع ما زال مستمرأء 
فلن يكون معروفاً قبل سنوات إذا كان سينتج من الممارسات المتبعة 
الممارسات المتبعة خلال مرحلتي البدء والتطوير من أفضل 
الممارسات على أساس أنه تم اتباعها في مشاريع سابقة. 


3-7 هيكلية نظام إدارة المباني الآلي 


تم تصميم هيكلية نظام إدارة المباني الآلي (845) بحيث يمكن 
إجراء العمليات البرمجية على المكوّنات عن طريق فرق مورّعة بما 
يتناسب مع نطاق الهيكلية. ويمكن إنجاز التطبيقات الخاصة 
بالمنتجات السابقة وعملية نقلها عن طريق المراكز المتخصصة. 
وسوف تتطور المواقع الخارجية لتصبح مواقع متخصصة بمرور 
الوقت؛ ولكن في مراحل عمل البرمجة الأولية» ستقوم الفرق بتطوير 
البنية التحتية مثل المكوّنات الخاصة بإنشاء قاعدة العمل. ولذلك» 
سوف تكون الهيكلية الناتجة عملية ومنشأة وفق المقاييس لأنه كان 
هناك مشاركة دولية فى عمليات البرمجة منذ البداية. إضافة إلى ذلك» 
للك من حمسيس تكو افونا ستهورة 1 و 
المصممين» بالتحديد» أن يكون حجم المكوّن الواحد أقل من 60 
ألف سطر من الشيفرة البرمجية (11005) بلغة برمجة #©. وكان 
هذا ناتجاً من الرغبة في أن يكون حجم الفريق البرمجي الذي يعمل 
على هذه المكوّنات عن يعد صغيرا. 


يوضح الشكل 1-17 وصفاً للبنية الهيكلية لنظام إدارة المباني 
الال 
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الحهينة 


الشكل 1-17: الهيكلية العليا لنظام إدارة المباني الآلي (8/4.5) 


تم تنفيذ خطة المشروع باتباع الممارسات التقديرية التي تم 
وصفها في الفصل الثامن. فقد كان مدير المشروع يعمل جنباً إلى 
جنب مع رئيس المصممين ليتم تقدير حجم الشيفرة البرمجية 
المصدرية لكل مكوّن من المكوّنات التي كان من المتوقع تطبيقها في 
المشروع خلال مرحلة التحضير. وقد تم تجزيء العمليات البرمجية 
المتوقعة للمشروع إلى وحدات برمجية» وتم تحديد الجهد المتوقع 
بذله وحجم الفريق اللازم لذلك لكل مكوّن من المكوّنات. وقد تم 
تخصيص مجموعة من المكوّنات للوحدات البرمجية وللمواقع 
البرمجية المتوقعة أيضا. وتم تحديد الموارد الداخلية اللازمة لحوالى 
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نصف المهام البرمجية التي سيتم تنفيذها. وتم افتراض أن النصف 
الثاني ستقوم المواقع الخارجية بتوفيره» وتم بذل جهد كبير في 
التخطيط للجهود التي سيتم بذلها في تأهيل هذه المواقع الخارجية 
وإحضار الأعضاء المهمين إلى الفريق المركزي خلال المراحل 
المبكرة بحيث يصبحون قياديين لفرق برمجة المكوّنات التي تعمل 
عن بعد. 1 

لقد بُذل جهد لا بأس به في اختبار إمكانية إعادة استخدام 
المكوّنات بدلا من إعادة إنشاء بعض المكوّنات الضرورية. وطرحت 
هذه التحديات العديد من الأسئلة التى تتعلق بمناسبة الوظائف 
والتقنيات؛ ولكن بسبب النقص الكبير ف الموارد المتاحة» تم بذل 
كل جهد متاح لإيجاد مكوّنات مناسبة لإعادة استخدامها أو تعديلها 
بشكل طفيف بحيث يمكن إعادة استخدامها بدلا من إعادة عملية 
التاق الصيفر: 


كذلك» وبسبب النقص الكبير في الموارد البرمجية المتاحة» تم 
طلب العديد من المصادر من الخارج. وعلى الرغم من أنه من 
المعروف أنه سينتج من إضافة مواقع برمجية جديدة تعقيدات في 
إدارة المشروع» وُجد أن استخدام شركتين خارجيتين سوف يساعد 
في تقليص المخاطر السياسية وتوفير مرونة أكبر عندما تكون هناك 
حاجة لتوظيف عدد كبير من المبرمجين. 


بذلت جهود كبيرة مقدماً في عمليات البرمجة في كل من 
البواقم المائسية وني مرفي دسل الك وباعدي ههه امسر 
الكبيرة في تتبع واختبار العمليات البرمجية الشاملة ليتم استخدامها في 
مرحلة التحضير. وتم تحديد أهداف كل مرحلة شهرية خلال فترة 
الأربعة شهور للمرحلة التجريبية. 
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4-7 التخطيط للمشروع 


تم التخطيط للمشروع باستخدام ممارسات التقويم التي تم 
شرحها في الفصل الثامن. وعمل مدير المشروع جنباً إلى جنب مع 
رئيس التصميم لوضع تقويم لحجم شيفرة البرمجة اللازمة لكل عنصر 
يُتوقع تطبيقه للمنتج خلال مرحلة البناء. وتم تقسيم مشروع التطوير 
المتوقع إلى فترات برمجية تكرارية وتم تحديد تقويم الجهد ومعدل 
حجم فرق العمل لكل من مكوّنات المنتج. وتم توزيع المكوّنات 
على الفترات البرمجية التكرارية وعلى مواقع التطوير المتوقعة. كذلك 
تم تحديد الموارد المحلية اللازمة لتنفيذ حوالى نصف المهام. وأما 
النصف الآخر فقد كان متوقعاً أن يتم تنفيذه في المواقع البعيدة» وقد 
تم بذل الجهد في وضع خطط جديرة بالاعتبار لتأهيل هذه المواقع 
البعيدة وإحضار الموظفين الأساسيين للعمل ضمن الفريق المركزي 
خلال المراحل الأولى من المشروع بحيث يصبح أعضاؤه قادة لفرق 
التطوير التي تعمل عن بُعد. وبُذلت جهود مهمة في اكتشاف إعادة 
استخدام المرشحين لاكتساب بعض العناصر اللازمة بدلا من بنائها. 
قادت هذه التحقيقات إلى إثارة العديد من التساؤللات فى ما يخص 
الأمور الوظيفية والتقنيات الملائمة؛ لكن وبسبب العجز الكبير في 
الحوارة القاعةع: ذل حمهود قات فى سكو و على ١‏ لعق اين العالاقية 
الكى حكن 'إعادةامسكدانها أ محدياي] تمشح مناوفية لإغاذة 
الاستخدام بدلاً من بنائها من الأساس. إضافة إلى ذلك» ونظراً إلى 
العجز الكبير في الموارد المتاحة للتطويرء يتم الاستعانة بالمصادر 
الخارجية وهو أمر مزعج. إن إضافة مواقع تطوير إضافية يضفي 
المزيد من التعقيد إلى إدارة المشروع» ومع ذلك أخذ هذا الأمر في 
الاعتبارء فكان الشعور السائد أن الاستعانة بشركتين خارجيتين 
سيساعد في الحد من المخاطر الناجمة عن الأمور السياسية ويوفر 
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مرونة إضافية عندما يكون عدد المبرمجين المطلوب توفرهم كبيراً. 

ونظراً إلى وجود موقعين خارجيين وموقع داخلي ثالث» تم 
إطلاق الجهود التجريبية قبل عمليات التطوير الشاملة. وقد ساعد 
ذلك في تتبع عمليات التطوير موزرّعة المراكز أثناء مرحلة البناء. وقد 
تم تحديد أهداف الفترات البرمجية لكل شهر أثناء فترة الإطلاق التي 
تبلغ مدتها أربعة أشهر. 


5-7 إدارة المشروع 

يوجد في كل موقع من المواقع المشاركة في عملية تطوير نظام 
إدارة المبانى الالى مدير للمصادر يعمل محليا للقيام بالعمليات 
الإدارية لأعضاء الفريق في الموقع. ويوجد أيضاً مدير عام لبرنامج 
نظام إدارة المباني الآلي يقوم بقيادة الفريق الإداري للبرنامج. ويوجد 
لدئ المدير المركزي للتطوير مديرا تزويد يعملان لديه في إدارة 
الروابط في المواقع الخارجية التي تعمل عن بعد. 

وقد كان مسؤول التصميم مسؤولاً عن اتخاذ القرارات التقنية 
وإيجاد حلول التداخلات التقنية. وهذه الوظيفة مهمة في المشروع إذ 
تضطلع بمسؤوليات كبيرة. كما يوجد مسؤول عن مهندسي المتطلبات 
المركزيين توكل إليه مسؤولية إنشاء وتحليل النماذج الخاصة 
بالمتطلبات التي تم استقاؤها من فريق التسويق الذي قام بوضع 
طلبات أصحاب المصلحة فى التطبيقات ذات التخصصات المختلفة. 

وتم تخصيص كل مكوّن من مكوّنات نظام إدارة المباني الآلي 
إلى فريق برمجي يعمل عن بعد. ويوجد في الفريق الذي يعمل عن 
المتخصص بتحديد أهداف المرحلة الزمنية لفريق برمجة المكوّنات 
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الذي يعمل عن بُعدء ولكن الفريق الذي يعمل عن بُعد هو الذي 
يقوم بالتخطيط للوصول إلى هذه الآهداف. 


الشهرية الخاصة بمراجعة العمل التى عُقدت بالتناوب بين موقعى 
الولايات المتحدة وسويسرا. وتم تحديد برنامج زمني للاجتماعات 
التي تتم فيها عمليات المراجعة لعدة ايام. ويتضمن البرنامج 
اجتماعات حول الوضع الحالي للعمل واجتماعات لطرح المعلومات 
مع وجود أنشطة اجتماعية لتحسين المهام الإدارية وبناء الفريق. 


6-7 دروس مستفادة 


لقد كان لكثير من الدروس والعبر المستفادة من مشروع نظام 
إدارة المباني الآلي علاقة بعمليات التواصل بين أعضاء الفرق 
الموزّعة. وفي مرحلة مبكرة» قضى فريق التصميم ثلاثة أسابيع في 
الموقع المركزي» ومن ثم أسبوعين في مكاتبهم الأصلية. وكان لذلك 
أثر جيد نسبياء وكان الفريق قادرا خلال هذه الفترة على العمل على 
تنظيم المهام ذات الطبيعة التعاونية (مثل اجتماعات التصميم)» وأيضاً 
المهام التي يتم إنجازها بشكل فردي (مثل كتابة وصف الهيكلية). 
ولدى كل عضو من أعضاء فريق التصميم الصغير هذا مكان مخصص 
للعمل في الموقع المركزي. وتم تخصيص غرفة اجتماعات 
للاجتماعات الخاصة بالتصميم. ولذلك» كانت أقصى مسافة بين 
أعضاء الفريق في الموقع المركزي خلال الأسابيع الثلاثة الآولى» 
خمسة عشر متراً على الأرجح. ونتيجة لذلك» كان هناك مستوى عالٍ 
من التواصل بين أعضاء الفريق. إضافة إلى ذلك». تحقق أكبر وأفضل 
قدر من التواصل عندما كان يجتمع أعضاء الفريق في الموقع 
المركزي بشكل مستمر لتناول طعام الغداء» وذلك عندما كان الفريق 
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المحلي يستضيف فريق عمل من المواقع البعيدة في أحد المطاعم في 
المنطقة. قام مسؤول التصميم الهيكلي بقيادة فريق التصميم وقام 
بتسهيل مهام العمل وتحديد القرارات التي يتم اتخاذها حول أي أمور 
المتعلق بتصميم الهيكلية لا ينتهي أبدأأ.ء وأنه من الضروري تجزيئه 
إلى فترات عمل زمنية لاتخاذ قرارات فعالة حول التصميم ,طكنانةه2) 
(2002. ويعلم المسؤول الفعال عن المصممين الوقت المناسب 


التصميم لتوفير بدائل مناسبة. 


عمل مدير المشروع مع فريق التصميم في تكوين فكرة تقديرية 
للجهود التي سيتم بذلها في عمليات التصميم والوقت الزمني اللازم 
لذلك. وكان من الواضح منذ البداية أن مدى المنتج المطلوب 
لمشروع نظام إدارة المباني الآلي أكبر من المشروع الذي أخذت 
الشركة على عاتقها أن تنفذه في البداية. استخدم مدير المشروع 
متطلبات التسويق» ووصف الهيكلية» وأدوات تقدير التكلفة» 
والبرنامج الزمني» والمعلومات المتعلقة بالجهود التي تم بذلها في 
مشاريع سابقة من أجل وضع تصور مبدئي للتقديرات المتعلقة بتكلفة 
التطوير والفترة اللازمة له. 


في وقت لاحقء» وعندما كبر حجم الفريق ليشمل بعض 
الأنشطة مثل هندسة المتطلبات والتخطيط لعمليات الاختبار وتحديد 
العمليات والتخطيط لعمليات الدمج والنماذج الآولية وتصميم واجهة 
تطبيق المستخدم» تم إعداد الفريق ليعمل كوحدات وظيفية تتكون من 
فرق عمل في مختلف مواقع البرمجة. لذلك» أصبح الفريق موزعاً 
في مناطق جغرافية مختلفة» ونشأ بين أعضائه كمّ نسبي أكبر من 
التواصل وتنسيق أكبر ومشاكل فعلية أكثر مقارنة بفترة الأسابيع الثلاثة 
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الأولى. وخلال فترة الأسبوعين» عُقدت اجتماعات دورية بين الفرق 
في أحد مواقع البرمجة في كل مرة. ولوحظ أن الإنتاجية العامة 
للفريق لم تكن جيدة كما لو كان الأعضاء يبعدون عن بعضهم 
البعض خمسة عشر متراً على الأكثر خلال فترة الأسابيع الثلاثة 
الأولى في الموقع المركزي. إن تغيير موقع الاجتماعات بشكل دوري 
أصاب بعض الأعضاء بالإرهاق جراء السفرء كما عانوا مشاكل 
جسدية أثرت في مدى يقظتهم وصبرهمء وغير ذلك. ونظراً إلى أن 
اجتماعات الفرق استمرت لعدة أيامء تم وضع برنامج زمني لزيارات 
أعضاء الفرق بحيث تكون مدة الرحلة أسبوعاً واحداً على الأرجح. 
ووفقاً للبرنامج الزمني؛ على الأرجحء فإن هذا قد يعني السفر خلال 
الغطلة الأسبوعية ما يوثر فى :وقت أعضاء الفريق االتتصهي العائلة 
من أزواج أو أبناء. ولتفادي ضياع الوقت المخصص للعائلة» قد يلجأ 
بعض أعضاء الفريق إلى استقلال رحلات طيران عابرة للقارات بحيث 
يلتحقون باجتماعاتهم مباشرة. وفي بعض الحالات» قد ينتج من قلة 
النوم أن تصبح هذه الاجتماعات مرهقة جسدياً. 


بمرور الوقت» تم إدراك أهمية تنظيم أعضاء الفريق لتحسين 
التواصل بين أعضاء الفريق الذين يعملون في الأنشطة التي تحتاج إلى 
تعاون في المراحل المبكرة للمشروع. لكن» عملية نقل أعضاء الفريق 
إلى الموقع المركزي كانت معقدة بسبب القيود المتعلقة بالتكلفة 
المادية والقيود الشخصية للأعضاء المميزين في الفريق. الأمر الآخر 
الذي نتج من التوزيع الكبير للفرق هو أنه حين وجود أعضاء الفرق 
في مكاتبهم الأصليةء يتم عادة التواصل بهم للمساعدة في إيجاد 
حلول لمنتجات سابقة. لذلك» فبالإضافة إلى أن أعضاء الفرق 
بعيدون عن الموقع المركزي». فقد كانوا أيضاً عادة ما يصبحون 
يعملون بشكل جزئي في مشروع نظام إدارة المباني الآلي. بعد فترة 
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من الوقت» تم اتخاذ قرار بأن يتم جمع أعضاء الفرق المهمين 
ليكونوا موجودين في الموقع المركزي» ولكن نتيجة لذلك اختل 
البرنامج الزمني للمشروع بسبب الوقت الذي تم فيه اختيار المرشحين 
المرشحين إلى دول أجنبية. وفقاً لهذه الدراسة ودراسات أخرى 
أيضاًء نعتقد أن المهام ذات الطابع التعاوني والمتعلقة بهندسة 
البرمجيات في المراحل الأولى كتصميم الهيكلية» تتطلب فريقاً 
صغيراً منظماً مشابهاً للفريق الذي كان يعمل خلال الأسابيع الثلاثة 
الأولى في الموقع المركزي. 


بسبب وجود شركتين برمجيتين تابعتين لشركة سيمنز في 
سلوفاكيا والهند تقومان بتوفير المصادر الخارجية» كان من السهل 
ملاحظة الفرق في الممارسات التي يقوم بها هذان المزودان. وقد 
كان هناك حاجة لأن يعمل الأعضاء المهمُون من المواقع التي تعمل 
عن بُعد في الموقع المركزي خلال المراحل الأولى بحيث يتم 
تدريبهم لقيادة فرق برمجة المكوّنات حين عودتهم إلى مواقعهم 
الأصلية خلال مرحلة التحضير. وقد لمسنا الفائدة الكبيرة من هذه 
العملية التنظيمية ولم نُسنَأ من التكلفة الإضافية التي تم تحملها نتيجة 
نقل أحد الأعضاء من دولة ذات تكلفة معيشية منخفضة إلى الولايات 
المتحدة. وكان الفرق بين الدوكدن المزودتين في حجم الدعم الذي 
بنقل أحد المهندسين الذين يعملون لديه بالإضافة إلى عائلته إلى 
الولايات المتحدة للتدريب. وقام المزود الآخر بنقل المهندس فقط 
وجهة نظر أعضاء الفريق المركزي لأن المهندس كان يعود بشكل 
مستمر إلى وطنه فى العطل لزيارة العائلة. وفى أسوأ الحالات» فإن 
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هذا يؤثّر سلباً في الأهداف المرجوة من وجوده للأسابيع الثلاثة 
الأولى المخصصة للموقع المركزي والأسبوعين اللاحقين في المواقع 
الخارجية. ويعتمد تحقيق الأهداف المرجوة من عمليات النقل على 
حالة العضو الذي تم نقله وعلى طبيعة العمل» ولكنا نعتبر أن نقل 
العائلات لمدة ستة شهور أو أكثر هو من الممارسات الأفضل فى 
هذا المشروع. ا 

كما في مشروع الأاستديو العالمي» قمنا بعمل تحليل للعلاقات 
الاجتماعية (58214) (انظر الفصل الثالث عشر من هذا الكتاب) فى 
هذا المشروع. وظهرت تحليلات العلاقات الاجتماعية في أتماط 
التواصل بين أعضاء الفريق في جميع المواقع الخاصة بالمشروع. أما 
البيانات التي يتم إدخالها إلى تطبيق تحليل العلاقات الاجتماعية هي 
رسوم بيانية للشركة تتضمن اسم وموقع كل عضو من أعضاء الفريق. 
وقد تم إجراء مسح عن طريق شبكة الإنترنت لكل عضو من أعضاء 
الفريق لوصف علاقته بفريق المشروع. وتحتاج عملية المسح إلى 
عشر دقائق تقريباً لكل عضو من الأعضاء حتى تكتمل» لذلك يُعتبر 
هذا الأسلوب في جمع البيانات من الأساليب المريحة. تكون نتيجة 
هذا التحليل رسومات بيانية تشابكية تظهر روابط التواصل بين أعضاء 
الفريق. وعلى الرغم من أن تطبيق تحليل العلاقات الاجتماعية على 
نظام إدارة المباني الآلي لم يُظهر اختلافاً كبيراً مع المشاريع المورّعة 
الأخرى» فقد أصبح من الواضح أن وجود عمليات تواصل إضافية 
أكثر فاعلية بين أعضاء الفريق الواحد وأعضاء الفرق المختلفة سوف 
يعود بالفائدة على المشروع. وكانت إحدى الملاحظات المهمة أن 
نصف الأعضاء المعينين في المشروع والذين يظهرون في الرسم 
البياني المتعلق بشركة المشروع كانوا يعملون بدوام كامل في 
المشروع فقط. وكون أعضاء الفريق يعملون في المواقع التي تعمل 
عن بعد بدوام جزئي يخلق صعوبات لمدير المشروع الموجود في 
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الموقع المركزي في عملية التخطيط للعمل وتنفيذ المشروع وفقاً 


فكرة مفيدة: 

احذر من الفرق الوهمية. 

تتطلب أنشطة معينة خلال المرحل الأولية من تصميم 
الهيكلية إلى مقدار كبير من التواصل بين أعضاء الفريق 
لإنجاز العمل. عادة ما تكون هذه الفرق صغيرة لكنها 
مكوّنة من خبراء فى المجالات المختلفة. لذلك» من 
العم قاذ التعلر ناها من أعهناء القريق مرحي 
المهارات المتنوعة. غير أنه عندما لا تكون هذه الفرق 
من مؤسسة واحدة» تكون عمليات التواصل مطولة. وقد 
تتأثر إنتاجية أعضاء الفريق أو جودة المنتج سلبياً بذلك. 
إضافة إلى ذلك» يعتبر هؤلاء الخبراء مصدر معلومات 
قيم للمؤسسة. وعادة ما يمتلكون سنوات عديدة من 
الخبرة. عندما يُوجَد هؤلاء الخبراء في المواقع التي تعمل 
عن بُعدء سوف يتم مقاطعتهم عن طريق توجيه الأسئلة 
لهم من أعضاء يعملون على منتجات تمت في مراحل 
سابقة. لذلك» غالبا ما تكون الفرق الوهمية غير ملتزمة 
بإنجاز عمل مكثف في وقت معين خلال المراحل 
المبكرة من المشروع حيث يكون الخبراء متاحين 
للتواصل مع أعضاء الفريق. 


7-7 الملخص 


على الرغم من أن مشروع نظام إدارة المباني الآلي ما زال 
يمكن ملاحظة عدد من الممارسات الجيدة المتعلقة بالتواصل بين 
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أعضاء الفرق الضخمة والمورّعة بشكل كبير. ويجب تنفيذ بعض 
الممارسات التي تم اتخاذها في المراحل المبكرة مثل عملية تصميم 
الهيكلية في موقع واحد لتوفير عمليات تواصل مكثفة بين أعضاء 
الفريق. ويجب أن يتم تجزيء العمل بحيث يتم إنجاز كل جزء في 
وقت معين لتسريع اتخاذ القرارات ولإظهار التقدم في سير المشروع. 
وقد يؤدي عمل الأعضاء أصحاب الوظائف المهمة جزثياً إلى 
الإضرار بتقدم المشروعء» خصوصاً إذا كانوا يوججدون بعيداً عن 


الفريق المركزي. 
المراجع 
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إن تطوير البرمجيات عملية ذات طابع معقّد. وقد بيّنت 
الدراسات التي أجرتها مجموعة ستانديش على مدى عشر سنوات أن 
نسبة كبيرة من المشاريع البرمجية تفشل أو تتجاوز الموازنة المقررة أو 
الجدول الزمنى أو لا تحقق الأهداف المنشودة (2000 ,همقصطه1). إن 
تابه و البرمجيات الموزّعة المراكز في عدة دول التي تختلف 
عن بعضها البعض في نظام التوقيت تزيد من تعقيد العمل. 


نلخص فى هذا الفصل المعوقات والقضايا الأخرى المتعلقة 
بمشاريع تطوير البرمجيات المورّعة المراكز. وقد تم تلخيص الأمور 
الآساسية: التي تتاولها هذا الكتاب لتوضيح الآلبة التي يمكن من 
خلالها تطوير البرمجيات بنجاح باستخدام فرق عمل موزرّعة في 
مناطق جغرافية مختلفة. وننصح القرّاء بأن يقوموا باستخلااص ووصف 
الممارسات الجيدة التي يرونها مناسبة» ويتم التشديد هنا على أهمية 
التجريب فى مجال هندسة البرمجيات. 
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1-8 قضايا تتعلق بتطوير البرمجيات الموزّعة المراكز 
تدفع الأمور الاقتصادية المتعلقة بتطوير البرمجيات المنظمات 
التجارية إلى اتباع أسلوب الانتشار العالمي. إن المرئب المنخفض 
لمهندسي البرمجيات الموجودين في مناطق معينة من العالم هو من 
الأمور التي تم أخذها بعين الاعتبار في المشاريع المورّعة كأسلوب 
ْنع لطرح المنتج في السوق بتكلفة أقل أو لإنتاج المنتج وطرحه في 
السوق بأكبر سرعة ممكنة. وتعزز المستلزمات والتقنيات الضرورية 
للاتصاللات كشبكة الإنترنت تعاون مهندسي البرمجيات في ما بينهم 
بوسائل إلكترونية. وكما ذكرنا في الفصل الأول من هذا الكتاب» 
تشمل بعض الأمور التي تحفز عمليات تطوير البرمجيات بشكل موزع 
يأتي (1999 باعمصصوك) : 
© محدودية القوى العاملة المدربة على التقنية اللازمة لبناء الأنظمة 
الحالية المعقدة. 
© توفر مهندسي برمجيات بكلفة أقل في دول كالهند والبرازيل 
والصين وأوروبا الشرقية. 
© إمكانية إجراء عمليات البريجة بشكل مستمر من دون توقف 
بوجود مهندسين يعملون في دول مختلفة في أنظمة توقيتها. 
© وجود بنية تحتية وتقنيات مسبقة خاصة بالتواصل وعمليات 
التطوير البرمجي. 
على الرغم من وجود أسباب تجارية قوية لتوزيع مراكز عمليات 
تطوير البرمجيات في عدة مواقع. يعمل لحساب مديري المشاريع 
البرمجية الآن أشخاص في دول أجنبية لم يلتقوا بهم قطء ولا يوجد 
لديهم الفرصة لإعادة النظر في جودة عملهم وتقويمه أو في تقدم 
عمليات التطوير. لقد انتهى الوقت الذي يمكن أن يقوم به مدير 
المشروع بالعمليات الإدارية عن طريق التجول بين الموظفين وحسب. 
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إضافة إلى ذلك» يقوم مديرو المشاريع البرمجية في الوقت الحالي 
بإدارة مشاريع أكبر من المشاريع التي اعتادوا على إدارتها نظراً إلى 
كون فرق العمل التي تعمل عن بُعد متوفرة وذات تكلفة أقل. وما 
يزيد من تعقيد المشروع والمخاطر المتعلقة به للتوصل إلى إنتاج 
ناجح كون المشاريع أصبحت أكبر بوجود أعضاء أكثر عدداء ووجود 
قائمة كبيرة من الوظائف التي يلزم برمجتهاء ووقت قصير لازم لطرح 
لمق يفن الننوق. 
هناك ثمة صعوبات محتملة قد تواجه مدير المشروع البرمجي 
الموزع المراكزء وهو ما تم الإشارة إليه في جميع أجزاء الكتاب 
(2001 ,اعاوطع11 0مه دنكاءه310). وتتضمن هذه الصعوبات: 
#اوعدوة عزايظ بين اليتود التعلقة بالعمل :والبال قفن تطير 
صعوبات في تنسيق العمل بين مواقع البرمحة المورّعة إذا لم يتم 
بناء الهيكلية للنظام ببحيت توافق مع اللهام الموكلة إلى المواقم 
التي تعمل عن بُعد والتي تكون عبارة عن وحدات مستقلة 
نسبيًا أو مجموعات عمل. 
© أصبح التنسيق من الأمور المهمة بسبب عدم تجانس العمليات. 
على سبيل المثال» قد تؤدي الاختلافات في تحديد الاختبارات 
اللازمة للوحدات إلى وجود تداخالات وتعارض» وفك بودن 
عدم الالتزام بالجدول الزمني في أحد المواقع في المواقع 
الأخرى. ل ل ل 
وقت مبكرء أو قد يؤدي الاختلاف في التوقيت إلى تسليم 
العمل من موقع لآخر بشكل متكرر نتيجة لعمليات التطوير 
المستمرة طوال الوقت. 
© يكون بناء نموذج للمنتج الذي سيتم تطويره أكثر صعوبة في 
المواقع المتعددة» ما يصعب من قدرة الجميع على فهمه وإدراك 
كنهه. وهذا بلا شك يحتاج إلى وقت أطول للتواصل وإيجاد 
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صيغة عامة يدركها الجميع» إذ إن أفراد الفرق التي تعمل عن 
بُعد يدركون طبيعة المنتج بشكل أفضل من خلال البريد 
الإلكتروني والمناقشات الهاتفية. إن احتمالية الوصول إلى 
مسؤول الهيكلية في موقع عمله وطرح بعض الأسئلة عليه 
وطلب عرض ثيل للمنتج هي احتمالية محدودة للمبرمجين 
الذين يعملون عن بُعدء لذلك من الصعب تكوين رؤية 
مشتركة للجميع. 

© يوجد اختلاف في البنية التحتية بين مواقع البريجة المختلفة» 
يشمل طريقة ربط الشبكات ووسائل وأساليب تطوير 
البرمجيات والمختبرات الخاصة بالبريجة والاختبار واختلاف 
إصدارات العمليات والأدوات الخاصة بالتعديل. 


غالباً ما تكون أكبر المشاكل التي تواجه المشروع مرتبطة 
بعمليات التواصل بين المواقع لأن المشاركين في المشروع ذوو 
مستويات تقنية وثقافات مختلفة ومتنوعة ومعرفة مسبقة مختلفة فى 
مجال العمل المطلوب. فمن غير المحتمل أن يكونوا قد شاركوا ب 
في مشروع واحد مسبقاً؛ كما إنهم يملكون الخبرة في مجالات 
برمجية مختلفة ويتحدثون بلغات مختلفة. إضافة إلى ذلك» فمن غير 
المحتمل أن لا يكون المشاركون قد خططوا لاستخدام وسائل 
تواصل مع المواقع الأخرى نتيجة لعدم القدرة على الحديث معهم 
وجها لوجه. 


2-8 وصفة للنجاح 


استعرضنا في هذا الكتاب عدداً من العوامل المهمة للوصول إلى 
النجاح نعتقد بأنها تمثّل العوامل الأساسية لنجاح مشاريع تطوير 
البرمجيات الموزرّعة المراكز. ففي حين أن معظم هذه العوامل مهمة 
أيضاً في المشاريع المنتظمة غير الموزّعة» غير أنها مهمة بشكل أكبر 
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في مشاريع تطوير البرمجيات الموزّعة المراكز. ويجب أن يُنظر إلى 
عملية تطبيق هذه العوامل كاستثمار في مجال الجودة وتقليل أثر 
المخاطر المحتملة. وعلى كل حال» يجب أن ندرك بأن عوائد هذا 
الاستثمار تكون أكبر بكثير بوجود علاقة لفترة زمنية طويلة مع المزود. 
نشير إلى هذه العوامل المهمة للنجاح بشكل عام كما يأتي : 


© الحد من الغموض: إن عملية تطوير البرمجيات ذات طبيعة غير 
واضحة يكتنفها الغموض. ويتم التعامل مع وجود الكثير من 
عدم الوضوح والالتباس في المشاريع البرمجية عن طريق 
التواصل غير الرسميء والتي تتم بشكل أسهل إذا كانت 
الفرق المتعاونة غير موزّعة. وتتطلب مشاريع تطوير البريجيات 
المورّعة المراكز الكثير من الأفكار والعمل لتكوين توافق حول 
الطريقة التي سوف تعمل وتتواصل مما الفرق التي تعمل عن 
بُعد بحيث يحصل أفراد الفريق على المعنى المقصود لهام العمل 

© الوصول إلى أقصى حد من الثبات: إن لعدم الثبات في مجالات 
المشروع المختلفة تأثيراً سلبياً كما لتأثير عدم الوضوح. 00007 
التغير في الطلبات» وبالأخص التي تأتي في وقت متأخرء 
خطيرة ويجب مراقبتها والتعامل معها بحذر. كما يمكنها أن 
تؤدي إلى إبطاء العمل في مشاريع تطوير البريجيات الموزّعة 
المراكز بشكل كبير؛ لذلك»؛ نحن ننصح بأن يتم إنشاء مهام 
ثابتة للمشروع بشكل متأن مثلما يتم في عملية تحديد 
المتطلبات وإنشاء الهيكلية» حتى وإن تطلب ذلك تأحيراً في 
البدء في مرحلة الإنشاء للمنتج. ْ 

فهم العلاقات الترابطية: تحدد طبيعة الترابط الموجود بين المهام 
الموكلة للفرق التي تعمل عن بعد مدى التنسيق اللازم بين 
هذه الفرق. 
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© لذلكء من المهم جداً فهم هذه العلاقات الترابطية للتخطيط 
للمشروع وتنفيذه. على سبيل المثال» إذا كان هناك مهمتان 
مترابطتان بشكل كبير»ء يفضل نقلهما إلى فريق واحد أو 
فريقين قريبين من بعضهما بعضاًء مع الأخذ بعين الاعتبار 
ضرورة أن تتقاطع فترات العمل للفريقين» وأن يكون 
الفريقان» كذلك» قد عملا مع بعضهما البعض من قبل. 

© تسهيل التنسيق: عندما تعمل الفرق على إنجاز مهام مترابطة» 
تبرز الحاجة إلى التنسيق في ما بينها. لذلك» يجب أن يتناسب 
مستوى التنسيق مع احتياجات العمل. والتواصل هو إحدى 
وسائل التنسيقء ولكن يمكن أن يتم التنسيق بين الفرق في 
العمليات والممارسات الإدارية وهيكلية المنتج» على سبيل 
المنال لا الحصر. ويجب الموازنة بين اختيار الجهود التى تبذل 
للتتسيق نين :هذه الأمور والمخاطر التي تنشأ: في خخال عدم 
التنسيق بينها. ويجب عدم الإممال وبذل الجهود اللازمة في 
تحسين العملية والعمليات التلقاتية ووجود أدلة مساعدة 
للعمليات البرمجية. 

© الموازنة بين المرونة والصلابة : تختلف الفرق التي تعمل عن بُعد 
في معرفتها والمعلومات التي تمتلكها عن مجال العمل واللغة 
والثقافة والممارسات المستخدمة داخل الشركة. يجب أن تكون 
العمليات البرمجية مرنة بما يكفي للتوفيق بين هذه 
ل 00 
المجالانة هن «العمابات: البرعية يده يشكل بواضت وحيد 
لأنها تُوفْر لمدير المشروع المعلومات حول سير عمل الفرق التي 
تعمل عن بعد في غياب ميزة القدرة على تتبع سير العمل عن 
طويق التجوال بين الفرق: 

لقد قمنا بتحديد نظام سير للعمل يرتكز على مبدأ المراحل 

المتتالية بحيث يتم تطبيق أفضل الممارسات التي يتم تدوينها عن 
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عوامل النجاح المهمة والحرجة. وتُعتبر الأنشطة التي تُنجز في مراحل 
مبكرة مثل تطوير نموذج للمتطلبات ووصف الهيكلية مهمةً وحرجة 
لتوفير فهم للعمل وتقسيمه إلى حزم يتم توزيعها على الفرق التي 
تعمل عن بُعد. ويتم تنفيذ أنشطة المراحل المبكرة عن طريق فرق 
صغيرة ومتجمعة تضم الأعضاء المميزين من المواقع المشاركة تعمل 
عن بُعد. ومن دون وجود توثيق جيد لمتطلبات المنتج وهيكلته» فإننا 
لا نتوقع أن تكون الفرق التي تعمل عن بُعد قادرة على إنجاز المنتج 
بنجاح. 

كما تشير أبحاثنا وخبراتنا السابقة إلى وجود مهام يمكن توزيعها 
على عدة مواقع» وأخرى من الأفضل أن يتم إنجازها في مجموعة 
منتظمة غير موزرّعة. على سبيل المثال» الأنشطة التي تتم في المراحل 
المبكرة» مثل تصميم الهيكلية» تحتاج إلى قدر كبير من التفاعل بين 
أعضاء الفريق وينبغي ألا يتم توزيعها على عدة مواقع. وبعد أن يتم 
تحديد هيكلية النظام وتحديد حزم العمل التي تكون نسبيا غير مرتبطة 
مع بعضها بعضاًء يمكن أن تبدأ الفرق البرمجية الموزّعة العمل على 
هذه المهام. 

إن عملية تجزيء العمل المعقد إلى مراحل متتالية بحيث تنجز 
كل مرحلة شهرياً من شأنها أن تساعد مدير المشروع الموزع في 
الحصول على رؤية أفضل وأكثر وضوحاً للتقدم في العمل وتساعد 
في تركيز الفرق الموزرّعة على تحقيق أهداف شهرية منسقة. ويتم 
اختبار النتائج البرمجية لشهر واحد خلال الشهر التالي والوقت الذي 
تستمر فيه الفرق البرمجية في البلورة والتحويل المستمر والمتزايد 
للمقاطع العمودية للمنتج إلى وظائف عمل. 

ننصح بإبقاء عدد الأعضاء في المجموعة الواحدة أقل من عشرة 
أشخاص» إذ إن هذا هو العدد الأفضل لتنفيذ عمليات برمجية 
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بحيث يتناسب مع حجم العنصر الواحد في الهيكلية» بحيث يمكن 
لفريق البرمجة الذي يعمل عن بُعد أن ينفذ أحد المكوّنات من خلال 
عشرة أعضاء وبزمن يقل عن سنة واحدة. 

تزيد عمليات التواصل في المشاريع الكبيرة والمعقدة والموزرّعة 
الراك وكا سر 0 لجر لصي نا رو عر المطيط را بسانلتي تم 
المساعدة في وضع القواعد التي تنظم طريقة تواصل الفرق مع 
بعضهاء وكذلك إنشاء بنية تحتية تدعم هذا. على سبيل المثال» 
الطبيعة السريعة والعابرة؛ ولكن». لأسباب تتعلق بتعقد الأمور 
المتعلقة بالمعلومات المفيدة للمشروع والتي قد تلزم المثابرة لفترة 
طويلة» يعضّل استخدام منتديات المناقشة. ويجب استثمار الكثير من 
الجهد الذهنى فى إنشاء استراتيجية سليمة لإدارة المعرفة. ويمكن 
استخدام الأدوات التعاونية مثل نظام 77111 لإدارة محتويات هذه 
المنتديات. 


تصبح الفرق المورّعة أكثر إنتاجية عندما تعمل معاً لفترة من 
الوقت. لذلك» يجب اعتبار استراتيجية نقل العمل إلى الخارج 
كاستراتيجية طويلة الأمد بحيث يتم تطوير موقع المبرمجين البعيد عن 
المركز الرئيس ليصبح مركزاً مختصاً ذا خبرة. ولا ننصح بأن يكون 
تقليل الكلفة على المدى القصير الهدف الوحيد من التطوير الموزع. 
وعلى الرغم من إمكانية تحقيق هذا الهدف غير أن خبرتنا في هذه 
المشاريع لم تؤكد توفيراً في التكاليف على المدى القصير. 

على الرغم من الطريقة الممتازة التي وضّح بها الفريق المركزي 
المواصفات» غير أننا نعتقد أنه ما زال من الصعب على أعضاء الفرق 
التي تعمل عن بُعد أن يفهموا كل ما يقرأونه» خصوصاً إذا لم تكن 
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لغة المشروع هي لغتهم الأم. إضافة إلى ذلك» حتى المشاريع 
المخطط لها بشكل جيد تكون عرضة للتغيير مع استمرار سير العمل 
ومواصلة إيجاد حلول لأي أمور طارئة» وتزداد صعوبة العملية حين 
العمل مع أجانب. لذلك» ننصح بالسفر لأهميته في المراحل المبكرة 
للمشروع» والتواصل وجهاً لوجه». وتبادل أعضاء فرق العمل لفترات 
طويلة في ما بين المواقع الموزّعة. 


8 3 تبادل أفضل المنهحيات 

يُشجع العمل في المشاريع على مشاركة أفضل المنهجيات في 
تطوير البرمجيات المورّعة المراكزء كما ورد فى فصول هذا الكتاب. 
ونتيجة للكم القليل المتوفر للعامة حول تطوير البرمجيات الموزّعة 
المراكز» نشعر أننا حددنا أفضل المنهجيات التى يمكن تطبيقها على 
المشاريع المستقبلية» على الأقل بالنسبة إلى مشروع من عدة مشاريع 
موثقة. وتتمثل المشكلة الأساسية في أن كل مشروع يُعتبر فريداً من 
نوعه ومختلفاً عن المشاريع الأخرى بشكل كبير من ناحية منهجية 
لا يوجد ضمانات أن المنهجيات التي تم استخدامها في أحد 
مشاريع أخرى. ومع ذلك. نحن لا نعتقد أنه يمكن تحسين انضباط 
مهندسي البرمجيات دون وجود مشاركة واسعة لأفضل المنهجيات 
والتجارب السابقة. يتم استخدام كتيب خاص بأفضل المنهجيات 
والتجارب السابقة والطبقات التنظيمية والأنماط المضادة لإضافة 
خيرات الآكتوين إلى خيرات مهنسى البرشعنيات لبفوموا بالقالى 
بالتخطيط الجيد لنجاح المشروع. 

من الطرق الأخرى لاختبار صلاحية المنهجيات المتّبعة فى 


003 


كل من جامعة كارنيغي ميلون» وجامعة هارفارد التجارية» والمعهد 
الدرلى الفقكر روصتا الملسلو هاف قن بانع الرو وج مج مدر ةتوت 
راكد ولاية بنسلفانياء وجامعة مر التقنية» وجامعة لومنيتش» 
والجامعة البابوية الكاثوليكية فى ريو غراند دو سول. وأدت هذه 
الج ركاف ب مطوي مدرو الاتدنهن العالفي على مدي عي 
سئوات؛ وكان المشروع كبيراً بحيث تمت الاستعانة بفريق من 
المبرمجين من طلاب الجامعات من خمس دول في أربع قارات» 
بحيث أمكن دراسة ثقافات وتنظيمات وأساليب تقنية مختلفة. وعلى 
الرغم من أن استخدام فرق من الطلاب لا يناسب البيئات الصناعية 
تماماء غير أن التحرية كانت عيارة عن عملية محاكاة مفبذة: على 
سبيل المثال» يحصل الطلاب الخريجون على درجات إضافية عن 
طريق مشاركتهم في المشروع كجزء من متطلب التدريب العملي بدلا 
من حصولهم على عائد مادي. 


على الرغم من ذلك» هناك احتمال أن يكافأوا على عملهم 
التجيد: كذلك» يمتلك: العدين مين الطلات"الحاليين التخريجين في 
هندسة البرمجيات خبرة صناعية جيدة؛ لذاء لا تختلف حيري 
ومهاراتهيج كثيرا خخ مهازات المينتسين الذيق ينم تزويدهم عن 
شركات خارجية نظراً إلى تكاليف أعمالهم المنخفضة. 


إن فائدة هذا المشروع التجريبي الكبرى هي عدم وجود مخاطر 
تجارية قد تنتج من فشل المشروع. لذاء يستطيع فريق الأبحاث 
الاستفادة من: حالتي التجاح والفشل- كما يكن تطبرق التقنبات 
الواعدة والأدوات والعمليات بشكل تجريبي» بحيث تكون نتيجة 
ذلك تقليل المخاطر وليس الدخول في المخاطر المترتبة على تجريب 
أساليب جديدة. فليس ثمة مدير مشروع برمجي يرغب في أن يكون 
مشروعه مجالا للتجربة. 


104 


تم تجهيز هذا المشروع بحيث يتم جمع أكبر قدر ممكن من 
البيانات النوعية في كل مرحلة من مراحله. وقد أصبحت هذه البيانات 
متوفرة للباحثين في مجال هندسة البرمجيات. وبهذه الطريقة» يمكن 
أذة انكو ,ره أفممان هذا سكن أن كوك قينا وما 14 بكرن غيو 
مفيد في مجال تطوير البرمجيات المورّعة المراكز. 


4-8 الملخص والاستنتاجات 


أصبح من السهل الإفادة من هذا العالم باتساعه ,سقتسلءن,5) 
9005 خعيوضا السبية" إلى "عدي التمجانه. تزليين فى نينتا أن 
نقوم بتحليل الأمور الاقتصادية والسياسية المتعلقة بتطوير البرمجيات 
المورّعة المراكز. وهناك ثمة دليل قوي على أن العولمة هي توجّه لا 
البرمجيات المورّعة المراكز أمراً حتمياً. لذلك» نهدف إلى فهم الآلية 
التي يمكن من خلالها تحقيق نتائج جيدة في مشاريع تطوير 
البرمجيات المورّعة المراكز. ونعتقد أنه يمكن الإفادة من أفضل 
الممارسات والتجارب التي تم اقتراحها في المشاريع الضخمة 
والمعقدة والمنتظمة (غير المورّعة). فإذا كنت مهندس برمجيات» 
يجب أن تدرك أن عالم الأعمال التجارية في هذه الأيام يزيد من 
فرص العمل والتعاون مع زملاء في دول أخرى. ويجب أن تكون 
مستعداً لذلك» ونأمل أن تمتلك الخبرة التي تؤهلك للعمل مع 
مهندسين أجانب. ونأمل أن تستمتع في العمل بهذه الطريقة وبحياتك 
المتعلقة به» وأن تجد الوقت الكافي لتتمتع بحياتك بينما تقوم 


نأمل أن تجد بعض الاقتراحات والنصائح المفيدة والممارسات 
التي دار الحديث حولها في مجال مشاريع تطوير البرمجيات المورّعة 
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المراكز. وإن أفضل مكافأة يمكن أن يحصل عليها أي مهندس 
برمجيات هي رؤية المنتج الذي قام ببرمجته قيد الاستخدام. وستتاح 
للمهندسين الذين يعملون في المشاريع الموزعة الفرصة للسفر حول 
العالم» وسوف يتعلمون العمل مع أشخاص ذوي ثقافات وخلفيات 
مختلفة. اخ ا مدر المشاريع الموزرّعة 
ال ره المراكز. 
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الثبت التعريفي 


إصدار هندسى (ع35ع11 عستععمنوم) : تسليم تراكمى لحزمة 
العمل في نهاية كل فترة شهرية من فترات البرمجة التكرارية؛ حيث 
يتم في نهاية كل فترة برمجية تكرارية تجميع الإصدارات الهندسية 
التي تشكل جزءاً من المنتج القابل للتنفيذ. 

تنسيق (0000102605): إدارة الملحقات والروابط التي تتم أثناء 
العمل على إنجاز الأنشطة المختلفة. 

جدول زمني (»اسلعطء5) : خطة لتنفيذ مهام البرمجة والتطوير 
بحيث تحدد فيها الآزمنة المحددة لتنفيذ تلك المهام. 


خطة الإصدار (سهاط عقهءا»18) : وصف تسويقي رفيع المستوى 
لإصدارات المنتج العديدة المزمع تسويقها وبيعها. 


خطة البرمجحة والتطوير (2وا2 )معصممه065»1): خطة تتضمن 
تقديراً للجدول الزمنى للبرمجة وتحدد الموارد البشرية اللازمة 
وتكاليف التنفيذ. 


خطة التكامل والاختبار (سقاط )1»5 لسة سمناةمعء)ه1): خطة 
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تعرض كيفية دمج وتكامل خصائص ومزايا المنتج والاختبار اللازم 
بناءً على ترتيب إصدارها. 


خطة المشروع (5واط اءءزوءرط©): مستند يتضمن خصائص 
الإصدار وخطة البرمجة والتطوير وخطة الاختبار والتكامل وخطة 
الإصدار. 


عنصر/ مكوّن 8عهمم02©): كيان ذو قابلية توزيع وانتشار 


بشكل مستقل أثناء وقت التشغيل. 


فترة برمجية تكرارية (ه1)©:260): فترة تحدد عدداً من الفترات 
الشيرية” السريحة والى نودي بجموغها إلى الاسدال, القايل للسفيذ 
لجزء من المنتج 

فترة زمنية شهرية 0هنرم5): فترة مدتها شهر ضمن ملدة الفترة 
الزمنية البرمجية » وينتج من هذه الفترة إصدار هندسى 0 مرحلة 
التنفيذ. 


قدرة على التنسيق («ا)نلزطهم2© ه00هم:00:0©): قدرة الشركة أو 
المنظمة على إدارة الروابط التي تتم أثناء العمل على إنجاز الأنشطة 
المختلفة. 


مدير التزويد 21223862 #عناممه5): إحدى الوظائف فى المركز 
الرئيس » يقوم مدير التزويد بالمساعدة فى إدارة العلاقات والمشاريع 
مع المواقع التي تعمل عن بعد أو مع مزودي الوحدات البرمجية التي 
يجب تطويرها. 

مدير المشروع (7138385©7 أءأزه2:0): شخص مسؤول عن إعداد 
الخطة لدورة حياة المنتج كاملةً» ويقوم في المقام الأول بإعداد 
خطط المشروع حتفي المنتج المطلوب وتنفيذ تحليل المخاطر 
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وعرض الاستراتيجيات الخاصية للتخفيف من حدة وتأثير المخاطر. 

مدير المنتئج (213038561 2:0014) : شخص مسؤول عن المنتج 
في المقام الأول» ويعمل على تحديد احتياجات السوق في ما يتعلق 
بالمنتج» ويعمل على إعداد خطط الإصدار وذلك بتعريف وتحديد 
حزم الخصائص والمزايا التي تشكل حلولاً برمجية يمكن بيعها. 

مواصفات إصدار مزايا وخصائص النظام عمدعا 1 عتتطدع*1) 
(دمناوءقكءءم5: تجميع الخصائص وإضافتها إلى الإصدارات التي 

وحدة (©0010011): وحدة تنفيذ برمجية ثابتة. 

4 9و1آ02131: هما علامتان تجاريتان لمكتب البراءات 
والعلامات التجارية في الولايات المتحدة المسؤولة عنه جامعة 
كارنيغي ميلون. 

8105©: هو علامة تجارية مسجلة لشركة 18231. 

1 طريقة تحليل تبادل الهيكلية و5820 هما علامتا 
حذماث خامة بعامعة #إرقشن ياو 

700284و11311: هما علامتان تجاريتان لشركة اءوزمة0© 
01002 1اعماءع 11003 في الولايات المتحدة الأميركية و/ أو دول 
أخرى. 

17 : هو علامة تجارية مسجلة لشركة صن مايكروسيستمز 
في الولايات المتحدة الأميركية و/ أو دول أخرى. 
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آلاف السطور من شيفرة البرمجة 000 08 وعطاآ لمذكتامط1” :12100 


أجهز 3 له 1ع متهن يل 120151131 01 11501دهن) ع 2121102علستتتاكم1 :1420 


إدارة إعداد البرمحيات اع ع8 1/1212 8113:1101 00111 ع1ه 5011577 :501/1 
إدارة التهيئة ع1 01 تله تناع 00111 :01/1 
إدارة ا حودة ع طاعع 7/1212 :01021113 :01/1 
إدارة ا حودة الشاملة ا13ع7اع8 11212 010211137 10121 :101/1 


إدارة الغذاء والدواء الأميركية لم 101185 ع 2000 تخ٠داط‏ 


إدارة بالأهداف وعكناءء 06 ([إ6 الاعماعع 21322 :1180 
إدارة بالتجول ناوخ عسمتلله1717 نط عع 2م11 :118114 
ألو ب تحليل ع 515 [دمك 115ه0ع1120' عتتااءء ا نراءمخ :4115171 ذل 
للوقاملة اليكل 

إصدار ا 


411 


إصدار هندسى 11635 ع اأاعع ماع م8 :81 


إصدار خاص للاختبار عقوعاع 5 أوه1 :112 
أمر تغيير هند سي 0101 عقصقطن) 25تاععماع م8 :00] 
أهداف/ أستئلة/ قياسات وعتتاع ]1 /كدمتاأوعن1 0 /02[15© :711 /© /© 
بأسرع وقت ممكن عاطزووه2 حث ه500 دخ :ط ركم 
بحث و تطو اس 2 هك لع1ةه165 :لآ 
بر مجيات 0 
برمجيات جاهزة تجارية كأعطاك-عط 011 لماع تع صسصسهك :0015 


2 النسخة 908ل برنامج 1 و1]15م عاط بمتده 121[ 2 ونحول :2111313 ل 
افيه الشركاف السانة 

-م10ع067آ1 320 ماعتتوعوع16 101 ع تمدع 210 ع1اع511216 81110621 :1852111 
البرنامج الاستراتيجي الأوروبي للبحث والتطوير (في مجال عم 
تكنولوجيا المعلومات) 


5 نامج تحفيز طو يل الأمد ولع 210 12021176 حتت 1 -عمه.آ :1112 


بروتوكو ل نقل النص التشعبى 20001 تع أقهة 11 جرع ازعم :115 :11112 
بروتوكول الوصول المفتوح البسيط 1مء2:0]0 و5وعءعءة دوءم0 عامصسند :2م50 


بيئة التطو 0 المتكامل 8110 اأمعطامهاءنء10 لع 21 توعام1 :11018 
تبادل الفرع الخاص اعمة81 عت كط 283 
تحقق ومصادقة خخ 1 ع «منادع كت 17 :لكى 11 


تحليل باستخدام نظام احتساب النقاط ونةز[هصك غصزه© ممتاأعصتاظ :قمر 


تحليل شامل 15 010631 :1ن 


412 


تحليل الشبكة الاجتماعية 75م 11هنتطاء21 50021 :تذلازم 
تخطيط مشار يع 5 أاعء 2810 ع31 501377 ع1 امعن)-ء 1 تااعع ‏ لطعتم :52م 
البرمجيات ذات الهيكلية المركزية 

تخطيط و تنظيم 55 ,,11211611161111185 ,0182111211185 ,213101111185 :201141 
وتنفيذ وقياس 

تخمين 95 0ع117110-455 51117 1ه ووعنا0 0ع171110-4556 ع1تامعاءد :نخ لاد 
بري دفين علمي أو مين بري دفين الساذج 

تدفئة وتهوئة وتكييف عصطنه0160ه00 عن ع ,دهتنهلتامع؟؟ ,عمنتدعة :ىار 


الهواء 


تصميم محكو م بالخصائص 1 1011172 علاط تتااى :لالم 
تصميم رفيع المستوى معزوء<1 أعناعآلطع 811 :110كز 
تطوير البرمجيات المورّعة المراكز 6تعممملءت<1 عمهعطاه5 6106921 :051 
تغير القيمة عنللة 17 -01-مع مقط :0017 
تقرير عن مشكلة 011مع1] تمعاطه22 خط 
تقرير عن مشكلة معروفة 201ع]1 تمعاطه:2 تمصا :121 
تقرير مشاكل البرمجية 1ممع18 متمعاطه]ط ع1ها1ه50 :521 


تقنية تقو يم ومراجعة عتاوتصاءء1 اعترع1 ع 8722165 سدمروهءط :2811 


البز نامج 

تقويم مخاطر البرمجية ط1]151 ه5015 :5118 
تكامل نموذج نضج القدرة متك تع ع امآ 0111/1 :0111/11 
تكنولوجيا المعلومات لاع 10مصاءء 1 مناه ستتمكه1 :11 
تنفيذ الطريقة عن بعل 0 004طاء711 عامصطعه :15311 


413 


تبيئة جهاز موصو ل 1 م1071 اماع00 :0100 
تواصل بين العمليات 10 12161-01006599 :120 


الجامعة 51 عل علصة0 مهنظ آه تإانوء «تمتآ عتامطاهك امع تادوم :1105م 
البابوية الكاثوليكية في ريو غراندي دو سول 


جامعة كار نيغي ميلو ن لاع كتملآا دم1اع/ظا عأوعصته0 :01110 
جامعة ليميريك 01 ا 00 
جامعة مونموث 71517 102120115 :1/110 
جامعة ميو نيخ التقنية اعتصد/7 01 (إاأواعء نالمن] لمعتصطءء1 :111341 
ا جمعية البريطانية للحاسوب 501 لعا مم00 مم8 :805 


-455012 512202105 02220132 01 21105 0و5و4 د5عه 511 125لا ماه 0 ردت 


جمعية الخدمات الحاسوبية أو جمعية المقاييس الكندية مقا 
حمعية المعدات الحاسبة لإلاعمتطعة]1 عمتاناممه0 0 ومتكدء0و355 :0011م 
حاسوب شخصي م00 [أقمهومء5 :5200 
خطة تطو ير البر بجيات أتاعطنطامه10ء 107 50115721 :5102 
دورة حياة تطوير البرمجيات ‏ ماع عكنآ أتعسامماءء2 عتهسجقه5 :اده 


ذاكرة القراءة فقط القابلة 179مصسءك8ة نإلد20-0ع1 عاطمسصودمومءط :5014م 
120137 20-02179ع1 ع1طتتسمتصونع 2:0 ع1ط52ة81 الدع 1تاعه81 :58821031 

ذاكرة القراءة فقط القابلة للمسح والبريجة كهربائياً 

ذاكرة الوصول العشوائى 71201 ووععع ف لم10 :تفع 


زمن وسطى إلى حالة إصلاح 1نهم10-1 -عمطة] -صدء21 :211111 
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زمن وسطي إلى حالة فشل اانه 10-1 -06نة] -مدء 11 :21/1111 


زمن وسطى بين حالاات الفشل لله 1 عع تا 8 -ع مط ] -صدعء 21 :21181 


سطور من شيفرة البريحة ع0 ]0 وعمنآ :100 
شبكة الإنترنت العالمية ع1 1717106 177010 :11177177 
شبكة بيانات الخدمات 216137011 10218 وعع1كل56 0علوطوء م1 :15111 
التكاملية 
شبكة الصحة التكاملية 8115757011 طخلدع11 لع1ه عع م1 :11117 
شبكة محلية 8161011 وعتى 10621 :لضا 
ضمان ا حودة 0121119 :04 
ضوء محطة الإدارة خطع مآ 5121102 الاعمطاعع ممة11 :1151116 
طاولة عمل مدير المشروع طاعمعءطعا ه117 امع قصه]8 أعءزهعط :211117 
يقة (تحديد) المسار ا حرج 4ع طنةط لمعناتت :0211 
طلب إجراء تعديلاات +1005 5ه 1خهع 210011 :211 
طلب إجراء عن بعد له عتتتلعهه:2 عأم يعم :20ر1 
طلب تغيير هند سي 1011651 ع228ط1ئ) 11725عع اع م8 :1801 
عدد أسطر شيفرة البريحة الصافية ع000 01 وعمنآ غ216 :21100 


عدد سطور شيفرة البرمجة (المضافة أو 000 ]0 وعطنآ 18[ :121:00 


المعدلة) 

عملية تخطيط المنتج 95 21211111115 0011م :ممصم 
عملية موحدة منطقية 5و9 1011164 1210021 :1]11298 
عنصر ور ابط :101 201226) ع 0211م مامت :0320 


415 


عنوان الموقع الإلكتروني على الإنترنت :1.0966 70مع256 591ع لانملا :آ1انآ 


قاعدة البيانات 835 10318 :128 
فرص مضغوط 1015 اع مم1ه0 © :6010 
لحنة المراجعة الهندسية 0 111167 ع للاععم ع م8 :818 
لغة التوميز الممتدة 6 منك1 7211 غ1طتحمعاءتء :2011 
لغة النمذجة الموحدة 210061125 1110لا :11181172 
مايكروسوفت 111105011 :115 


5 ©1111 2011 01 00121101161 عاع مآ 16 تمع 2:0 :]1ط 
متحكم منطقي قابل للبريجة أو اتصالات خط الطاقة 
متطلب مهم من الناحية أمعتمعتتناوع1 أخصدع تمع اك :2113تتطءعاتطءعة ناكم 
الهيكلية 
جموعة إدارة الكائنات 1010© اتاعطاعع و ]1 أعء زط 0 :0110 


جموعة عمليات هندسة 1005© ووعءه22 عملععصتع مط عتهجاكه5 :518205131 


البرمجيات 

مجموعة مراقية المنتج 1010© 001101© أعندله: :200 
محاكي نظام حقل العمل اذك ممسعاونرك 21610 :كوم 
مختبر هندسة البرمجيات 220121017 ,] علتاعع ماعط عنه50157 :5181 


مدير معاملات مايكروسوفت 7ع1]928286! دمناعةوصةء1 16ه5هس 21 :115 


مراجعة نقدية للتصميم 1 لع زوء10 031191 :0101 
مزود خدمة بر امج تطبيقية 010 عن 1تدع5 املنوعتاومة :كم 
مشروع الأستديو العا مى أعءزهع 51010 010601 :052 


416 


مصفوفة هيكلية التصميم 271211 عتناأع )5 معاوءدآ :12511 


معالج الإشارة الرقمية :65501 518081 10121101 :1252 
معالحة إلكترونية للبيانات 5و0 12068 عتدمناءه81 :8108 
معدات :11177 


معهد أبحاث شركة سيمنزر ع0[ ,لاعتوعءوع ]1 ع0121م001) 5ماعمطعاك :501 
معهد هندسة البر بجيات 10501 ع طتاعع ماع م8 عننه 5015 :5181 


المعهد الو طنى الأمير كى عأنالتاكمآ 5128202105 ١12610221‏ معتعسة :2151م 


للمعايير 

مكتبات الربط الديناميكية 1127[ علصاآ عتستمصز2آ إنآآطآ 
ملايين السطور من شيفرة البريحة 200 7ه وعصنآ مه111ن81 :211:06 
منطقة العمليات الأساسية 9ث ووعه2:0 زعك]1 نط1 


منظمة المقاييس والمواصفات 5مه0ة2نهدعء0 كلعملسة)5 [2همتأقص نم1 :150 
الدولية 


مواصفات إصدار المخصائص متاو لاعوم5 عموعاعا عتبطدوءط :115 
مواصفات إصدار المكوّنات نم11 ااعطه م ص00 :015 
مو اصفات متطلبات 1 10101111115595 5 2ناعع11211 :11165 
التسويق 


مو اصفات متطلبات النظام 115 لم55 :5115 


موزع القيمة المضافة تعلاعوع؟ 0ع00خ-عسلة؟ :جلما 
نائب الر ئيس أمعلزوءء2 م171 :2 
نشر وتوزيع وظيفة الحودة لطعم :103مء10 ومأعصتاط (ائلهن0 :01210 


417 


نظام أمتة المباني 0ك 811108 :كمق 
نظام احتساب النقاط (للبرامج) 5مزه ممتأعمنع :م2 
نظام إدارة قاعدة البيانات ع5 712128611611 8356 10362 :1081/15 
نظام التحكم بالشيفرة المصدرية 2عاةؤئز5 1مناصه© ع00© عمنتناه5 :5005 
نظام التحكم بالمراجعة ع5 1م00 56915102 :105 


نظام الترميز 5 1210111231101 101 ع000) 512120310 لتو 1اعسخ :5011م 
الأميركى لتبادل المعلومات 


نظام مالي مع ةك لوأعسممماط :25 
نظام مراقبة البرنامج تطع 55 0001101 انو زمعم :05م 
نظام معالحة البيانات 1 210065511185 102128 :1025 
نظم المعلومات الصحية 3 11011211011 طالدء11 :1115 


نمذجة الكائن المضمن ذو عصنتاءله]2 0عنتمعةت0-اءءزط0 عصنا- لدع :1001/41 
الزمن ال حقيقي 
نموذج إزالة العيوب [عل70 01721 ع1 أعم1ء12 :121341 


نمو ذج لتو اصل [ع7100 أعءز0 أمعمهم ه00 0151111160[ :1000134 
البرمجيات المورّعة (على شبكة) 


نموذج لحساب تكلفة البرمجيات اعل710 2056© عتكناع 11و00 :0000110 


نمو ذج نضج القدرة اعله]7 واتتطه]8 «واتلتطومة© :1111© 
هندسة البر مجيات 501716 1ع 1ش اع ]مم00 :04518 
بمساعدة الحاسوب 

هندسة بر مجيات الجحودة 0102111 عنه 501 :5018 


418 


هندسة المتطلبيات ع 5ع :11 
هيكلية خط الإنتاج عتنااعع ا لطءعة عمناآ أعمصلمعط تضاط 


هصكلية و سيط 1لااعع ]لطع قىخ 2م8101 أوعناو ]1 أععزط0 00101 :730 حر8 001 


لتسهيل طلبات بين برمجيات (مختلفة اللغة) 


هيئة مهندسى 75 و16 هن7اءه1816 لله امعتتاععا8 01 عالكتاقم[ :181818 


الإلكترونيات والكهرياء 


واجهة بر مجة التطبيقات 11 51210111118 210 01ناهء أأممم :[طم 
واجهة المستخدم ععة عام[ وول :آلآ 
واجهة المستخدم الرسومية ععة 1 عام]آ توونا لمعتطمة:© :0101© 
وثيقة التصميم التفصيلية 1ع ناء100 معزوء2آ 0ء1زماء12 :ماماطط 


وثيقة التصميم رفيع المستوى 000110121 لعاوء10 أعناع .رآ لطع 81 :1111010 
وحدة المعالحة المركزية أنطلآ عستووعءه:2 1وامع :0210 
ورشة عمل حول سمات الجودة «مطمانه/1 عانطتنلك نختلمن0 :04157 
وصول مباشر للذاكرة 95ل 112017 أععناط :حاط 


الو طنية للملاحة مه خ1اهنائنسنسلخ ععدم5 مه 05 تاقممععة 21360221 أذك كح 
الحوية والفضائية (ناسا) 


419 


الفهرس 


عا 

الاجتماعات اليومية السريعة: 
6 57 

إدارة إعداد البريجيات: 285 
6 288. 292 294. 304 

إدارة التهيتة: 288 2289 
2 294. 304. 329 

أساليب التواصل: 2305 
31 

أسلوب العمل الممتد: 256 

أمتلوتي الفريق الافشرامي: 
378 

إصدار بيتا: 64) 66 

الإصدار التزايدي: 2.64 199 

إصدار خصائص النظام: 167- 
0 176-175» 178» 180 


الاقتصاد العالمىي: 27» 53 
- -_ - 

البرمجة الانحدارية: 79 

البريحة التكرارية: 193. 199 

البرمجة المزدوجة: 246 2.57 
149 

البريحيات السريعة: 235 249 
5 149. 204. 246 

برجية (28178): 2.100 372 - 
373 

برمحية (16آ[045): 319 2325 
3 2337 340 - 2342 
8 349 

بروتوكول نقل النص التشعبي: 


287 2281 .9 


البريد الإلكتروني: 8 2209 


2280 .273 - 2722 1 
2398 2333 2.302 0 
402 

البنية التحتية: 225» 235 237 
45 50 6177 2250 
7 - 2271 273 - 2274 
7 281. 284 - 2286 
8 294 295. 2326 
8 338 - 2339 2347 
0 398 


:هت 

تبادل الهيكلية: 63» 264 
213 

تحديد وحدات العمل: 2.127 
9 - 130 

التحليل الشامل: 2»63 2232 
2 2.354 378 - 379 

تلبل الكائن البرضي + 371 

تحليل النقاط الوظيفية: 203 

تحليلات العلاقات الاجتماعية: 
359 

تخطيط الكفاءات: 261 


002 


الترتييات اللوجستية: 109 


64 - 3 


تطوير البرمجيات: 4 5» 23 - 
7 29 2.30 33 - 236 


8 43 2.46 49 2.51 
3 56» 58» 60 - 2,62 
710 79-2776 93 
4 98 99. 2,102 
14+ 105)» 119)» 122 
4 » 126 127)» 135غ» 
7.» 141 142غ» 145 
1» 154 156)» 159 
0» 162» 183» 187 - 
8 194. 204. 209 
0» 213» 227 - 2228 
0 2237 2.245 247 - 
1» 254 256)» 2258 
1» 2264 267 - 2268 
1- ع 6212 82178 :6250 
3 285 - 289)» 2291 
4 298 299. 302 
6 312 313» 319 - 


»338 325 323 0 
395 2355 2349 0 
2,403 2399 398 6 
406 - 05 

تعدد الثقافات: 238 239 

تغير القيمة: 134» 321 

تقويم مخاطر البرمجيات: 155 

تنسيق الهيكلية: 153 

التنظيم بين العملاء والمبرمجين: 
46 

تنفيذ البريحة : 174 

التواصل: 9 24 225 229 
55 37» 50» 54» 56 
7 59. 263 268 2103 
5 108.» 125)» 133غ» 
9) 149 152» 161غ» 
7 - 188. 193» 2201 
0 212 213» 216» 
2221-0 223 224». 226 
228» 230 237». 239 
0 248. 251 2252 
7 270 - 2274 2785 - 
0 2293 297 - 2.314 


- 331 329 2.327 4 
- 360 .»355 340 2 
2375 6367 365 2 
396 2.390 389 .387 5 

403 402 400 


توثيق الهيكلية: 2118 137غ» 


369 2 


ذم 


جدول الجدوى: 142 
الجدول الزمنى: 36. 249 69 


ع 40 75 77 - 6917 
01 » 131.» 147 2.148 
4» 156.» 160 161» 
٠169 168 65‏ 172غ» 
5 158 191» 2194 
3 228 2249 2252 
1» 353 355» 3585 
9- 4395 397 


الجهد الأقصى: 182 


داخ- 


138 .124 2.111 ».6 


خصائص النظام: 87 288 


٠.116 ).92 0‏ 130غ» 
167 - 6176-2175-1172 
8 1580. 185. 213 


لمن 
سمات الجودة: 107» 123 


2 


م سس - 
شبكات الأمان: 248 
الشركة متعددة الحنسيات: 


- 373 2371 - 366 8 
214 

شيفرة البرمجة: 103. 127» 
9 188 2.189 2215 
1 346. 383 

الشيفرة البرمجية: 2152 175» 
191 192. 195 198ء 
01 209. 213. 2226, 
5 - 2288 2326 2329 
0 381 

5200-6 
طبقات الأدوات البرمجية: 127 


1024 


يقة التحليل الهيكلي المتبادل: 


63 - 64 
طلبات التغيير: 58» 304 


ع 5-5 
العقل الجماعى: 305 
6 2199 


11 172غ» 


- 287 »)269 »)256 »1 


2326 322 310 ».38 


2346 345 329 - 8 


356 5 


ايلات المشوية 
57 

عملية الإبلاغ عن العيوب 
وتتبعها: 330 

عطلية إذارة لعفيو 773861 

22726 4 


66 


)5 


93 69 


04 


عملية إدارة الشيتنة: 85 - 
09 292 294 2304 


349 0 


229 
عملية إدارة المخاطر: 5 


2147 145 ».125 ».6 


5»؛» 161» 330 

عملية تبادل الأعضاء: 307 

جكرة مايل السحتكات 
الاجتماعية: 2308 310 - 


349 2 

عملية تخطيط البرمجة: 171» 
1522 

عملية التصميم المنطقي: 254 

عملية التصميم الهيكلي: 2124 
341 352 - 2353 2357 
4372-71 386 

عملية التصميم والبريجة: 2214 
2 329 

عملية تقويم أداء الفريق: 331 


عملية ضمان الجودة: 25 


ذذ» 61 278 83غ» 2,93 
06 157. 214. 2219 
1 245 - 248)» 2255 
4 327 - 2328 345 
316 

العملية المنطقية الموحدة: 30» 
2334 


015 


العملية الموحدة العلائقية 


القياسية: 65 
قات 
الفترات البرمجية التكرارية: 
ذ7 ٠.17/1 ٠.93‏ 181» 
55 195 2197/7 2.199 
4,. 383 


فرق البرمجة: 253 64 65» 


67 7/5 - 276 2758 2.90 
237 121» 123 2.124 
6 138 140)» /167غ» 
6 185 186)» 2193 
9» 204 209 2214 
6 219)» 223.» 2228 
0 362 
الفريق المركزي: 4 266 
55 /1587» 193.» /197غ» 
9+ 200.» 211 2.2216 
65 - 219» 221» 226 
--229:-:.623:1- 2933 
8 252غ» 256 - 257» 
0 261» 2263 2267 


1250 278 4275 2 
2287 - 286 284 - 3 
- 326 324 - 322 6 
- 335 )333 329 7 
342 340 - 338 6 
2352 »)348 - 345 3 
2383 382 361 0 

402 391 85 


تزيق ووقة العو 115 
د ق- 
قاعدة المعرفة: 279. 281» 
214 


قاكل :ووشة العم +114 
دك - 
كاتك ووه العه 115 


5 
لغة النمذجة الموحدة: 62 


63 279 83». 93غ» 2131 


33726257 9 


المتحكمات الهيكلية: 115» 123 


006 


متطلبات الووكلية:: 6 263 


2.109 .107 106 9 
2119 2117 »)115 14 
»133 128 »125 13 
141 

المتطلبات الوظيفية: 276 93 
65 256 321 2326 
4 2335 2337 364 

مخططات التسلسل: 131 

مدير التزويد: 2.64 214» 
6 219غ» 225 2231 
3 2 2237 239 - 2240 
2 27 2 - 6330 2332 
5 2 348. 380 


مراكز الاختصاص: 193 
مرحلة التطوير: 6 58 


65م 70 92 135 - 
7 140 141. 146ء 
6 179 4.180 185ء 
6 4354 378 

المسار الحرج: 171. 2174 
152 


مشروع ©انآ0051): 319 - 


5 333غ) 337غ») 340 


349 - 348 2 


مشروع الأستديو العالمى: 25 - 


2267 239 38 31 7 
2286 2283 2277 2 75 
2389 2324 2322 9 

404 


مشروع نظام إدارة المباني الآلي : 


2377 »)2261 .245 21 

9 381 384 357غ. 
9 390 

مصفوفة هيكلية التصميم: 
0 342 


معهد هندسة البرمجيات: 106 - 


2141 »122 ٠111 » 07 
320 8 

الملكية الفكرية: 229 

منهج الجدول الزمني: 36» 
9 69 70 ذل كك 
7 101» 131» 147 - 
8 154. 156» 160 - 
1» 165.» 168 2169 
2 2.75 188 2191 


ادك 


2249 .228 .213 4 
2355 2353 261 2 
397 2395 2.359 - 8 

المنهجية: 24 227 235 277 
53 93 107. 109غ. 
5 118» 284 


منهجية سكروم: 30 
ميزان القوى: 229 


3 


الت 
نظام (ع115111): 319 2325 

2342 - 340 »337 3 
349 8 


نظام كلظ : 331.» 350 

نظام حقل العمل: 320 321 

نظام حوافز لفترات طويلة: 
262 

نظام السرعة: 50 

نظام الشبكات المقيدة: 287 

نظام العملية: 50 

نظام معالجة البيانات 085) 
(2000: 

نظام المعلومات الالية 5:5) 


362 .358 1 


375 366 »363 :2000( 


نظرية التنسيق: 304 305 

النقاط الوظيفية: 190 203 

النماذج البدائية: 58. 92 

النمذجة: 23)» 62 63» 279 
3 285 287 93. 2131 
9 2257 337 

النمذجة المرئية: 63 

نموذج البرمجة باستخدام 
الكائن: 371 

النموذج التكراري: 50 

ده بد 

الهجرة: 229 

هندسة البرمجيات: 23 2,24 
27 35 76 106 - 
7» 111 122. 127. 
141» 145. 203. 2215 
0» 320» 6.338 345غ. 


8 2395 403 405 
هندسة البرمحيات الوظيفية: 76 
هندسة المتطلبات: 2.25 58غ. 
61 2,63 


077 15-1 


0158 


9 80 82 88 2,90 
2233 9 94.) 98 /16غ2 
9» /1587» 213.» 2250 

386 65 


هندسة متطلبات العمل: 62 
الهيكل التنظيمى: 106» 121» 


2.188 2142 ».125 4 
2216 215 ».210 »7 
341 .324 2 


هيئة مهندسي الكهرباء 
والإلكترونيات: 246 


- وق - 

واجهة المستخدم: 187. 2200 
3 - 2.214 219. 2257 
335 

وحدة البرمجيات: 192. 195 

ورش عمل خصائص الجودة: 
63 

ووكنة لعب 107 111 
3 - 2117 123 

ينانا العواضب كعات 


302 


دليل تطوير البرمجيّات الشامل'*ا 


مسعد جر 
اهمها 
5011/0 
أمعمرزمماع/اع ا 
ةا الكتاب: 
() الكتاب الأول من تقنية المعلومات 
1. المياه المؤلف: 
3 2. البترول والغاز 
!| 3. البتروكيمياء 
0 
لع 4. النانو 
1 5 التقنلة الكدوية 
0 
(ا 6. تقنية المعلومات 
8 7. الإلكترونيات والاتصالات 
2 والضوئيات 
2 
1 8. الفضاء والطيران 
0 
.١ 2‏ الطاقة 
1 0. المواد المتقدمة 
3 0 
11. البيئة المترجمة: 
-44 
ا“ 
مدينة الملك عبدالعزيز 
للعلوم والتقنية18657 المنظمة الغربية للترجمة 


السلسلة:. تضم هذه السلسلة ترجمة لأحدث الكتب 


عن التقنيات التي يحتاج إليها الوطن العربي 
4 البحث والتطوير ونقل المعرفة إلى القارئٌ 
العربي. 

يركز الكتاب على التقنيات الملائمة لإدارة 
فطلوين االبرمجنات والاقصالات القاامالة 
بالإضافة إلى التنسيق والتحكم بتوزيع البيثات 
ا ل 
الاستراتيجيات المتعلّقة بمراقبةٍ نوعية البرامج 
الخاصة بتوزيع البرمجيّات المطوّرة وإنتاجهاء 
ضوني مما فيه الأفضال السارسااف وإكدرها 
ده هذا لجل 
والج كدر ساتقازنه اأسكااة متغصحن مماندية 
البرمجيّات - جامعة بنسلفانيا. 
ماثيو باس: مهندس برمجيّات - جامعة 
كارنيغي ميلون. 
نيل موليك: مهندس برمجيّات. ومتخصص 
بالتسويق الدولي - جامعة كارنيغي ميلون. 
دانيال ج. باوليش: دكتوراه ‏ الهندسة 
الكهربائية - معهد نيويورك للبوليتكنيك. 
جيورغين كازميير: دكتوراه ك4 الرياضيات 
وعلم الحاسوب - جامعة ميونيخ 
التكنولوجية. 
مرفت سلمان: ماجستير 4 أنظمة إذارة 
االعاليماات > جامعة عقارق اللعرومية اندرو ااسايت 
العليا. 


الثمن: 25 دولاراً 1994-9- 
أومايعسها | 
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